Интеграция приложений на основе WebSphere MQ
Административные команды и доступ к объектам менеджера очередей
Система очередей сообщений позволяет контролировать исполнение административных команд и доступ к объектам менеджера очередей - к самому менеджеру и очередям. 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:
Рис. 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 имеет единую структуру на всех платформах и основан на простой системе из десятка команд:При создании приложений, обеспечивается поддержка интерфейса 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. В ней было ряд нововведений, в том числе:
В 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 (различных видов очередей, каналов, процессов, сервисов или служб). Он осуществляет контроль и управление всеми его объектами и обрабатывает поступающие запросы от прикладных программ.Для создания любого объекта 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. | Менеджер очередей удален, однако в конфигурационном файле осталось его имя, как имя менеджера по умолчанию. Описание менеджера по умолчанию может быть неверным. |
Процесс создания менеджера:
увеличить изображение
Рис. 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 – максимальное количество сообщений, которые могут находится в очередях и транзакции по их отправке еще не завершились;
увеличить изображение
Рис. 2.8. Создание менеджера очередей (Шаг 2)
В этой форме:
Use circular/linear logging - с помощью данного флажка можно выбрать тип логирования на вновь создаваемом менеджере;
Log Path – указывает путь, где будут созданы лог-файлы;
Log File Size - размер файла логирования, размер созданного файла будет в 4 раза превышать указанное число;
Log Primary Files – количество первичных файлов логирования;
Log Secondary Files – число вторичных файлов логирования.
увеличить изображение
Рис. 2.9. Создание менеджера очередей (Шаг 3)
В этой форме:
Start Queue Manager – при установленном флажке менеджер очередей будет активизирован непосредственно сразу после создания;
Create Server Connection Channel – установка данного флажка позволит создать канал (SYSTEM.ADMIN.SVRCONN) для удаленного управления объектами менеджера через протокол TCP/IP.
увеличить изображение
Рис. 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 необходимо установить следующие программные продукты или их более поздние версии:
Для начала инсталляции необходимо, в зависимости от комплекта поставки, запустить файл запуска программы установки и следовать инструкциям, появляющимся на экране. После сообщений о подготовке и начале установки должно появиться меню (рис.2.1), в котором нужно последовательно выполнить пункты:
увеличить изображение
Рис. 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):
увеличить изображение
Рис. 2.4. Основные инструменты работы с WebSphere MQ
Прежде чем перейти к описанию работы с вышеуказанными утилитами рассмотрим процесс деинсталляции WebSphere MQ. Можно отметить, что в ходе многолетней эксплуатации авторам не приходилось производить переустановку WebSphere MQ в системах промышленной эксплуатации, что говорит о высокой надежности работы. Тем не менее предлагается следующий алгоритм переустановки WebSphere MQ:
Интеграция приложений на основе WebSphere MQ
Каналы
Каналы 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)
Интеграция приложений на основе WebSphere MQ
Использование механизма триггеринга для автоматического старта каналов
Используя механизм триггеринга можно сделать так, чтобы каналы отправители, перешедшие в нейтральное состояние Inactive в результате истечения времени, указанного в атрибуте Disconnect Interval автоматически переходили в состояние Running при появлении в соответствующей трансмиссионной очереди сообщения. Для этого существует два способа: с использованием процесса и с использованием системной очереди инициализации. Рассмотрим вариант с использованием процесса.Для каждой трансмиссионной очереди нужно создать:
Теперь рассмотрим второй способ автоматического старта канала отправителя без использования процессов. Для реализации второго способа требуется лишь установить атрибуты трансмиссионной очереди:
Имя системной очереди инициализации может быть использовано в атрибуте 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 в единицу (рис.4.13).
Рис. 4.13. Выравнивание счетчика сообщений
Если использовался способ остановки с прерыванием транзакции, то выполнить пункт контекстного меню Resolve и выбрать метод обработки сообщений, для которых транзакция не завершилась (рис.4.14). Commit - передать сообщения, Back out - выполнить откат транзакции.
Рис. 4.14. Метод обработки сообщений с незавершенной транзакцией
Эту процедуру следует выполнить когда устранены все неполадки, приведшие к остановке каналов или переходу в неопределенное состояние. Если в сети существуют проблемы со связью, то канал отправитель может не перейти в состояние 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:
Создадим объекты на менеджере QM_Win2000_REP:
удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ (рис. 4.4), имеющая атрибуты:
Рис. 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 - данные, которые могут быть переданы выполняемой программе.
Для запуска процесса необходимы условия:
Предположим, что необходимо информировать пользователя о приходе каждого сообщения в очередь FOR_USER_INF.Q. Рассмотрим шаги для реализации поставленной задачи:
Создать файл c:\temp\trig.bat, содержащий строку
net send user1 Пришло сообщение в очередь FOR_USER_INF.Q
который будет посылать сообщения пользователю user1,
увеличить изображение
Рис. 4.11. Консоль WebSphere MQ Services
Поместить тестовое сообщение в очередь 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&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 - файл, содержащий текст сообщения.
Считать сообщения из очереди можно с помощью программы 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
Авторизация и доступ к объектам
В предыдущей лекции были рассмотрены примеры создания интерфейсов передачи данных без учета вопросов авторизации и доступа. 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. Может принимать значения:
Administration authorizations - опции команды для авторизации на выполнение действий. Может принимать значения:
Generic authorizations - опции авторизации для групповых операций. Может принимать значения:
Опции команды 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
setmqaut -m QM_Win2000 -n Vip*.* -t queue -p test1 -get
setmqaut -m QM_Win2000 -n Win2000_HPUX.?Q -t queue -p test1 +dlt +dsp
setmqaut -m QM_Win2000 -n A1 -t queue -p test1 +all
setmqaut -m QM_Win2000 -n ?2 -t queue -p test1 +all
setmqaut -m QM_Win2000 -n **.CQ -t queue -p test1 +all
setmqaut -m QM_Win2000 -n NO*.Q -t queue -p test1 +get
setmqaut -m QM_Win2000 -n DEAD_LETTER -t queue -p test1 +put +browse +get
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.
Внутренние команды могут состоять из нескольких операторов. На первом месте стоит оператор, указывающий действие. На втором месте указывается тип объекта, к которому применяется первый оператор. Типы объектов указываются следующими операторами:
Основные операторы, которые, как правило, стоят на первом месте внутренней команды.
Подробный синтаксис команд можно узнать из документации [11].
Пример создания интерфейсов передачи данных в обе стороны между двумя менеджерами QM_Win2000 и QM_HPUX с адресами 198.32.100.26 и 198.32.100.16(1421), причем на менеджере QM_HPUX канал отправитель должен переходить в состояние running как только в соответствующей трансмиссионной очереди появляется сообщение. Для этого создаются объекты на менеджере QM_Win2000:
При создании объектов с помощью команды 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:
Команды для создания этих объектов будут выглядеть следующим образом.
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 под другой учетной записью.
Рис. 5.1. Форма настройки dcomcnfg
Рис. 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. Для удаленного управления менеджером очередей необходимо:
AMQ8416: MQSC timed out waiting for a response from the command server.
Далее с помощью команд MQSC можно управлять объектами удаленного менеджера.
Интеграция приложений на основе WebSphere MQ
Добавление и исключение менеджера из кластера
Рассмотрим два способа включения в кластер менеджера, расположенного на компьютере с операционной системой UNIX. Имя менеджера очередей – QM_HPUX, IP адрес – 198.32.100.16, порт для службы «Listener» - 1421. Для включения в кластер данного менеджера очередей и создания необходимых кластерных каналов выполним команду из командной строки на компьютере с операционной системой UNIXrunmqsc QM_HPUX
и далее:
define channel('TO_QM_HPUX') + chltype(clusrcvr) conname('198.32.100.16(1421)') + cluster('THUNDER')
define channel('TO_QM_Win2000_REP') + chltype(clussdr) conname('198.32.100.26(1415)') + cluster('THUNDER')
define qlocal('HPUX.CQ') cluster('THUNDER')
В результате последней команды мы получаем информацию о кластерной очереди 'Win2000.CQ' менеджера QM_Win2000, что говорит о доступности информации о кластерных объектах кластера 'THUNDER':
DESCR(WebSphere MQ Default Local Queue) CLUSTER(THUNDER) CLUSQMGR(QM_Win2000) CLUSDATE(2004-10-05) ALTDATE(2004-10-05) CLUSQT(QLOCAL) PUT(ENABLED) DEFPSIST(NO) QUEUE(Win2000.CQ) QMID(QM_Win2000_2004-10-05_15.42.55) CLUSTIME(17.36.17) ALTTIME(15.49.29) TYPE(QCLUSTER) DEFPRTY(0) DEFBIND(OPEN)
Существует способ добавления менеджера в кластер с помощью WebSphere MQ Explorer в графическом режиме. Для этого следует:
увеличить изображение
Рис. 6.8. Ввод имени кластера.
увеличить изображение
Рис. 6.9. Выбор менеджера очередей, являющегося репозиторием.
увеличить изображение
Рис. 6.10. Ввод имени кластерного receiver канала и IP адреса менеджера QM_HPUX.
увеличить изображение
Рис. 6.11. Ввод имени кластерного receiver канала и IP адреса менеджера QM_Win2000_REP.
Кластер WebSphere MQ
При создании систем передачи данных, нередко возникают ситуации, когда некоторые серверы недоступны в течение какого-то времени или работают посменно. Кластер WebSphere MQ это объединение менеджеров очередей, которые могут располагаться на различных платформах. При правильной настройке объектов кластера, приложения помещают сообщения в кластерные очереди, даже если один из менеджеров очередей становится недоступным, а после возобновления связи с ним приложения могут забирать сообщения из локальных кластерных очередей. Каждый менеджер может иметь очереди, доступные для других менеджеров кластера без использования удаленных (remote) и трансмиссионных (transmission) очередей и каналов. При включении менеджера в кластер автоматически создаются кластерные каналыsender и receiver на каждом таком менеджере, причем receiver - канал у каждого менеджера может быть один. В процессе передачи данных используются системные очереди SYSTEM.CLUSTER.REPOSITORY.QUEUE и SYSTEM.CLUSTER.TRANSMIT.QUEUE, которые были созданы еще в процессе установки WebSphere MQ. Менеджеры очередей в кластере могут исполнять роль, как клиентов, так и серверов. Серверы делают доступными очереди для членов кластера, а также для приложений, которые управляют процессами передачи сообщений и генерируют ответные сообщения. Клиенты могут помещать сообщения в кластерные очереди на любых менеджерах и также получать ответные сообщения, но только из кластерных очередей, находящихся на локальном менеджере. Менеджеры очередей кластера доставляют сообщения в нужную очередь и обмениваются информацией о кластерных объектах, несмотря на то, что обычно клиенты, расположенные на разных платформах не могут установить соединение друг с другом.Объектами кластера могут быть менеджеры очередей, очереди и каналы. Информация обо всех объектах кластера называется репозиторием. Часть ее хранится в системной очереди SYSTEM.CLUSTER.REPOSITORY.QUEUE и обновляется с помощью SYSTEM.CLUSTER.COMMAND.QUEUE и встроенных в WebSphere MQ механизмов репликации. Репозиторий может быть полным (full) и частичным (partial).
Информация между репозиториями менеджеров передается с помощью кластерных каналов sender и receiver. Она включает в себя как собственно сообщения, так и любую информацию об изменении статуса менеджера или о добавлении/удалении объектов в кластер. Кластерный канал receiver принимает информацию от других менеджеров. На каждом менеджере необходимо иметь как минимум один кластерный канал receive. Все сообщения передаются через SYSTEM.CLUSTER.TRANSMIT.QUEUE. Если один из менеджеров кластера перестанет быть доступным, то сообщения, предназначенные для его очередей, останутся в этой очереди на соответствующем менеджере.
Один менеджер очередей может быть включен во множество кластеров. То же самое относится к очередям. В данном случае создается объект WebSphere MQ именуемый NAMELIST.
Рассмотрим процесс создания кластера и включения в него менеджеров на разных платформах. Создадим кластер из существующих на одном компьютере (IP адрес 198.32.100.26) менеджеров очередей QM_Win2000 (менеджер по умолчанию) и QM_Win2000_REP (порт для listener – 1415). Процесс состоит из следующих шагов [12].
увеличить изображение
Рис. 6.1. Create Cluster Wizard
увеличить изображение
Рис. 6.2. Ввод имени кластера
увеличить изображение
Рис. 6.3. Ввод имени менеджера для первого репозитория
увеличить изображение
Рис. 6.5. Ввод имени receiver канала для второго менеджера QM_Win2000
увеличить изображение
Рис. 6.6. WebSphere MQ Explorer, показывающий кластер THUNDER
Следует сказать, что кластерные каналы могут использоваться как обычные для передачи сообщений между менеджерами очередей. Так, создав необходимые объекты на удаленном менеджере, не включенном в кластер можно использовать имя кластерного канала receiver для создания sender канала, и наоборот. Использовать эту возможность не рекомендуется, так как для четкости построения потоков передачи данных целесообразно использовать для каждого потока свои объекты WebSphere MQ, дифференцируя количество потоков с количеством и размером сообщений в каждом потоке. Подробнее на вопросах производительности мы остановимся в лекции 7.
Таким образом, создав объекты WebSphere MQ (очереди и каналы) на одном менеджере можно видеть их «отображение» на другом, управление очередями становится доступным как на одном, так и на другом менеджере. При создании очередей теперь необходимо указывать, в зависимости от их назначения, доступна ли она кластеру и какому именно. При создании очередей через WebSphere MQ Explorer первый вопрос задается сразу после ввода имени очереди и нажатии на кнопку «Ok». При положительном ответе форма создания очереди переходит на закладку «Cluster» и предлагает выбрать имя доступного кластера. Отметим тот факт, что при создании кластерных очередей директории для них не создаются, как это было в отношении локальных очередей. Вся информация будет находиться в SYSTEM.CLUSTER.REPOSITORY.QUEUE и будет передаваться в такую же очередь на менеджеры, включенные в кластер.
Рассмотрим пример передачи сообщений в кластере. Создадим локальную очередь с именем Win2000.CQ (CQ – cluster queue) на менеджере QM_Win2000:
runmqsc QM_Win2000 define qlocal('Win2000.CQ') cluster('THUNDER') refresh cluster('THUNDER') end
Создадим локальную очередь с именем Win2000_REP.CQ на менеджере QM_Win2000_REP:
runmqsc QM_Win2000_REP define qlocal('Win2000_REP.CQ') cluster('THUNDER') refresh cluster('THUNDER') end
Поместив тестовое сообщение в очередь Win2000_REP.CQ с помощью контекстного меню WebSphere MQ Explorer (рис. 6.7) на менеджере очередей QM_Win2000 можно его увидеть на менеджере QM_Win2000_REP. И наоборот, поместив тестовое сообщение в очередь Win2000.CQ на менеджере очередей QM_Win2000_REP можно его увидеть на менеджере QM_Win2000.
увеличить изображение
Рис. 6.7. Помещение тестового сообщения в удаленную кластерную очередь.
WebSphere MQ под управлением MSCS
В данной части лекции мы подразумеваем, что читатель хорошо знаком с работой Microsoft Cluster Server (MSCS). Для установки WebSphere MQ на кластер NT система должна удовлетворять следующим требованиям:или
Процедура установки WebSphere MQ и помещение менеджеров под контроль MSCS описывается следующими шагами:
где qmname – имя менеджера очередей.
На этом процесс переноса менеджера под управление MSCS можно считать завершенным. Остается только проверить работоспособность менеджера, проимитировав сбой с помощью команды MSCS «Initiate Failure», вызываемой с помощью контекстного меню группы, в которую входит менеджер очередей. Кратко о преимуществах работы WebSphere MQ под управлением MSCS. Очевидно, что это делает работу WebSphere MQ исключительно надежной в целом, если по тем или иным причинам один сервер кластера выйдет из строя или временно будет не доступен.
Прежде чем деинсталлировать WebSphere MQ необходимо вывести менеджер очередей из под контроля MSCS. Для этого нужно сначала перевести ресурс менеджера в offline, а затем уничтожить все ресурсы. Уничтожение ресурсов (кластерный диск, IP адрес, IBM WebSphere MQ MSCS) не приведет к удалению менеджера очередей. Далее выполнить команду haregtyp /u. Рекомендуется сохранить все объекты менеджера (например с помощью программы saveqmgr, описанной в лекции 5), затем удалить менеджер, создать его заново и восстановить все объекты.
В заключение лекции можно сказать, что мы рассмотрели работу WebSphere MQ в самом кластере WebSphere MQ и под управлением кластера MSCS. Главное отличие состоит в том, что при работе с кластером MSCS «виртуальный» менеджер кластера всегда доступен, если даже один из серверов выходит из строя. Управление объектами WebSphere MQ остается точно таким же, как и при работе с локальным менеджером, и никаких преимуществ в управлении и настройке мы не получаем. В случае использования кластера WebSphere MQ наяву очевидные преимущества, связанные с отсутствием обязательного создания и настройки трансмиссионных (transmission) и удаленных (remote) очередей и каналов. Но если возникают проблемы на одном из менеджеров кластера WebSphere MQ, то считывание сообщений из локальных кластерных очередей менеджера становится проблематичным до восстановления его работоспособности.
Интеграция приложений на основе WebSphere MQ
Дополнительные средства администрирования
В каждом случае при возникновении ошибок WebSphere MQ дает ее номер.С помощью документации [7], [13] или программы WebSphere MQ Messages and Codes Helper, доступной по адресу ftp://ftp.software.ibm.com/software/integration/support/supportpacs/individual/ma0k.zip, можно выяснить суть ошибки и исправить ее. Внешний вид программы представлен на рис.7.2.
увеличить изображение
Рис. 7.2. Внешний вид программы WebSphere MQ Messages and Codes Helper
Кроме расшифровки кода самой ошибки, данная программа дает варианты причин, по которым могла произойти ошибка и методы устранения ее.
Помимо вышеуказанной программы существует множество программ, облегчающих работу с объектами менеджеров очередей. Рассмотрим программу WebSphere MQ Administrator (Support Pac MO71). Программа имеет графический интерфейс и позволяет производить любые действия с объектами как локальных, так и удаленных менеджеров. Внешний вид программы представлен на рис.7.3.
увеличить изображение
Рис. 7.3. Внешний вид программы WebSphere MQ Administrator
Добавить в список доступных менеджеров для управления новый удаленный менеджер можно, выполнив пункт меню File => Add Location. На экране появится форма, изображенная на рис.7.4.
увеличить изображение
Рис. 7.4. Форма добавления удаленного менеджера очередей
В поле Location нужно ввести имя отображения в списке менеджеров, доступных для управления, а в поле Queue Manager - имя удаленного менеджера, выставить флажок в поле Client и нажать кнопку Configured.
В открывшейся форме (рис.7.5) в поле Channel Name нужно ввести имя канала типа Server Connection или Client Connection (данный канал должен быть создан на удаленном менеджере), с помощью которого будет осуществляться подключение к менеджеру, IP адрес с указанием номера порта для службы listener и нажать кнопку Ok.
увеличить изображение
Рис. 7.5. Конфигурация параметров подключения к удаленному менеджеру
После того, как форма закроется, нажать кнопку Add в предыдущей форме. Подключаемый удаленный менеджер должен отобразиться в форме, показанной на рис.7.3 под именем QM_HPUX. Рассмотрим пример, показывающий как можно оперировать с сообщениями, находящимися в очереди на этом удаленном менеджере. Допустим, нужно переложить второе сообщение из очереди Win2000_HPUX.Q в очередь TEMP.Q. Для выполнения операций просмотра, удаления или перемещения сообщений нужно выполнить следующие действия.
Поместив курсор на менеджер QM_HPUX выполнить пункт меню Commands => Queue List.
В открывшейся форме (рис.7.6) при нажатии на кнопку Refresh появится список очередей менеджера QM_HPUX.
Выбрав очередь Win2000_HPUX.Q нажать кнопку Browse и в открывшейся форме (рис. 7.7) нажать Refresh.
Поместить курсор на второе сообщение, в поле Target Queue ввести имя очереди, в которую нужно переместить сообщение (в нашем случае это TEMP.Q) и нажать кнопку Move. После этого второе сообщение будет перемещено в очередь TEMP.Q. Соответственно для копирования сообщения нужно нажать на кнопку Copy, для удаления – Delete. Кроме этого, данная программа в отличие от Message Browser утилиты WebSphere MQ, позволяет просматривать до 10000 сообщений, причем на экран можно вывести полный текст сообщения с помощью кнопки Open, а с помощью кнопки Detail свойства сообщения. Вставить сообщение между другими сообщениями в очереди нельзя.
увеличить изображение
Рис. 7.6. Список очередей менеджера QM_HPUX
увеличить изображение
Рис. 7.7. Список сообщений очереди Win2000_HPUX.Q
Для этого следует переместить все сообщения после требуемого в другую очередь, затем поместить нужное сообщение и вернуть все перемещенные обратно. Несомненным преимуществом программы является возможность удаления сообщений даже если очередь эксклюзивно открыта другим приложением. Отображение списка объектов в данной программе статично, то есть для получения списка объектов в данный момент времени следует нажимать кнопку Refresh. Последняя версия программы доступна по адресу: ftp://ftp.software.ibm.com/software/integration/support/supportpacs/individual/mo71.zip.
Существуют программы, позволяющие перемещать текст сообщения в файл и наоборот, текст, содержащийся в файле помещать в тело сообщения. Примером такой программы может служить программа rfhutil, являющаяся частью Support Pac IH03 (IBM WebSphere Business Integration Message Broker display, test and performance utilities). Программа доступна по адресу: ftp://ftp.software.ibm.com/software/integration/support/supportpacs/individual/ih03.zip.
Внешний вид программы представлен на рис.7.8. Данная программа может быть полезна в случае, когда надо исправить текст внутри сообщения, находящегося в очереди. Для этого можно переместить текст сообщения в файл, исправить его, а затем положить обратно в очередь. Следует учесть, что данная программа при считывании сообщения удаляет его из очереди. Поэтому, во избежание потери текста сообщения, желательно скопировать его в какую-нибудь промежуточную очередь с помощью программы WebSphere MQ Administrator (mqmonntp) и оперировать с ним.
увеличить изображение
Рис. 7.8. Внешний вид программы rfhutil
Остановимся еще на одной важной программе saveqmgr, позволяющей записывать все объекты менеджера очередей в файл в формате команд MQSC для командного процессора runmqsc. Синтаксис команды выглядит следующим образом:
saveqmgr -m[-r] QmgrName –f FileName -h -v -s -i
где:
-m – создается скрипт для локального менеджера.
-r - создается скрипт для удаленного менеджера. Для подключения к удаленному менеджеру достаточно создать трансмиссионные очереди и каналы в обе стороны.
QmgrName – имя менеджера.
–f FileName – имя файла, в который будет записан скрипт. По умолчанию saveqmgr.tst.
-h – выводит справочную информацию на экран.
-v – указывает в какой версии MQSC нужно формировать команды для создания объектов. Может принимать значения 1, 2, 5, 51, 52 или 53.
-s – не создает команды MQSC для объектов, начинающихся на SYSTEM*.
-i – пропускает создание команд для поврежденных объектов.
Используя созданный данной командой скрипт-файл, можно легко восстановить объекты менеджера очередей в случае переустановки системы, если состояние объектов менеджера не удается восстановить, например, при поломке жесткого диска. Рекомендуется при создании или изменении свойств какого-нибудь объекта, но не реже раза в неделю использовать данную программу для сохранения информации объектов для каждого менеджера очередей. Данная программа доступна по адресу ftp://ftp.software.ibm.com/software/integration/support/supportpacs/individual/ms03.zip
Очередь недоставленных сообщений и восстановление данных
Практически все события, за исключением обработки non persistent сообщений, фиксируются в различных лог файлах WebSphere MQ. Существует два вида лог файлов. В первый записываются сообщения об ошибках, а во второй все изменения состояния объектов менеджера, включая обработанные persistent сообщения. Файл ошибок имеет формат, который легко прочитать с помощью любого текстового редактора. В него записываются события, связанные со стартом или остановкой менеджера и каналов, ошибки установки соединения, ошибки приема или отправки сообщений, например с некорректным форматом или ошибки конвертации, связанные с кодовой страницей. Одним словом, все события, связанные с обеспечением деятельности всех менеджеров очередей, созданных на данном компьютере. Расположение этих файлов задается при первоначальной установке WebSphere MQ. Например, для платформы Windows по умолчанию они расположены в каталоге C:\Program Files\IBM\WebSphere MQ\Errors и имеют название amqerrXX.LOG, где ХХ – номер файла. Второй тип файлов имеет специальный формат и представляет собой журнал изменений свойств объектов. Кроме этого в него записываются все persistent сообщения, обработанные менеджером очередей. Для каждого локального менеджера создаются свои файлы. Например, для менеджера очередей QM_Win2000 на платформе Windows они расположены в C:\Program Files\IBM\WebSphere MQ\log\QM_Win2000\active\ и имеют имя s000000X.log, где X – номер файла. Напомним, что существует два вида логирования сообщений и изменений свойств объектов – линейный и круговой. Линейный вид логирования, в отличие от кругового, позволяет как записывать, так и восстанавливать состояние менеджера в определенный момент времени. Запись образа объектов менеджера производится с помощью команды rcdmqobj. Синтаксис команды имеет вид:rcdmqobj -m QmgrName -t ObjectType GenericObjName
где:
QmgrName – имя менеджера.
ObjectType – тип объекта. Может принимать значения nl или namelist для списка кластеров, prcs или process для процессов, q или queue для всех типов очередей, ql или qlocal для локальных очередей, qa или qalias для alias очередей, qr или qremote для удаленных локальных очередей, qm или qmodel для модельных очередей, qmgr для менеджера, * или all для всех объектов.
GenericObjName – имя объекта.
Встречаются ситуации, когда необходимо удалить файл очереди, содержащий сообщения. Это необходимо, например, при заполнении свободного пространства дисковой системы (тома), выделенной под WebSphere MQ на UNIX платформах. В этом случае WebSphere MQ сообщит, что объект данной очереди поврежден. Восстановить поврежденные как сознательно, так и в результате сбоя дисковой системы, объекты при условии линейного логирования, можно с помощью команды rcrmqobj. Синтаксис команды имеет вид:
rcrmqobj -m QmgrName -t ObjectType GenericObjName
где:
QmgrName – имя менеджера;
ObjectType – тип объекта;
GenericObjName – имя объекта.
В результате выполнения этой команды восстанавливаются не только очереди, но и persistent сообщения в очередях. Это возможно благодаря тому, что для каждого объекта менеджера ведется запись изменений его состояния, и так называемые точки checkpoint. Команда rcrmqobj повторяет все события, которые были с поврежденным объектом от последнего checkpoint до конца лог файла. Поскольку not persistent сообщения в файл не записываются, то они и не восстанавливаются.
При использовании кругового логирования поврежденные объекты следует удалить, а затем создать заново.
Кроме технических ошибок бывают еще и логические ошибки, связанные с неправильными настройками объектов. Если в локальной удаленной очереди указано неверное имя удаленного менеджера или очереди назначения, то сообщения все равно будут доставлены на менеджер, расположенный по адресу, указанному в канале отправителе, который использует соответствующую трансмиссионную очередь. Для обработки ошибочных или недоставленных сообщений существует специальная очередь недоставленных сообщений, которая указывается в атрибуте менеджера Dead-letter Queue в закладке Extended. Изменим пример из лекции 5, в котором при создании на менеджере QM_Win2000 локальной удаленной очереди Win2000_HPUX.RQ будет неправильно указана очередь, в которую нужно доставить сообщения:
ALTER QREMOTE ('Win2000_HPUX.RQ') + XMITQ('Win2000_HPUX.TQ') + RNAME('Win2000_AIX.Q') + RQMNAME('QM_HPUX')
Очереди назначения Win2000_AIX. Q на менеджере QM_HPUX не существует, однако сообщение все равно будет доставлено на этот менеджер в очередь DEAD_LETTER. Его можно просмотреть с помощью WebSphere MQ Explorer (рис. 7.1).
Просмотрев свойства сообщения, в закладке Dead-Letter Header можно увидеть код ошибки 2085, который говорит о том, что в заголовке сообщения существует неизвестный объект. В поле Destination Queue можно увидеть, что очередью назначения является несуществующая очередь Win2000_AIX.Q. Из данной ситуации есть три выхода:
Создать очередь Win2000_AIX.Q на менеджере QM_HPUX и перенаправить сообщение из DEAD_LETTER в нее с помощью команды:
runmqdlq DEAD_LETTER QM_Win2000
Далее ввести команду:
ACTION(RETRY)
и нажать
увеличить изображение
Рис. 7.1. Свойства недоставленного сообщения
сообщений в очереди превышает ее атрибут Maximum Queue Depth, то вновь поступающие сообщения также будут помещаться в очередь недоставленных сообщений.
Перенаправить сообщение в другую очередь, например в Win2000_HPUX.Q. В данном случае синтаксис команды runmqdlq будет выглядеть следующим образом:
runmqdlq DEAD_LETTER QM_Win2000
Далее ввести:
ACTION(FWD) FWDQ('Win2000_HPUX.Q') HEADER(NO)
и нажать Ctrl+d. Сообщения из очереди DEAD_LETTER будут помещены в очередь Win2000_HPUX.Q.
Удалить сообщение из DEAD_LETTER, исправить свойства локальной удаленной очереди Win2000_HPUX.RQ на менеджере QM_Win2000:
ALTER QREMOTE ('Win2000_HPUX.RQ') RNAME('Win2000_HPUX.Q')
и послать сообщение заново.
Второй способ можно использовать, когда переполнена как очередь назначения, так и очередь недоставленных сообщений. Если это не удается, то можно поступить следующим образом. Назначить в качестве очереди недоставленных сообщений новую очередь и перестартовать менеджер. Вновь поступающие сообщения будут помещаться уже в нее. Однако следует не допускать переполнения очередей недоставленных сообщений. Кроме этого, следует отметить, что простое перекладывание сообщения из очереди недоставленных сообщений в очередь назначения не даст нужного результата, поскольку недоставленные сообщения имеют свой собственный (MQDEAD) формат.
Иногда встречается случай, когда после перезагрузки менеджера очередей пропадают сообщения из трансмиссионной (transmission) очереди, несмотря на то, что ее атрибут Default Persistence установлен в persistent. В таком случае следует проверить этот атрибут в соответствующей локальной удаленной (remote) очереди и также установить его в persistent.
Перенаправление потоков
Потребность в этом приеме может возникнуть когда необходимо посылать "пачки" сообщений, например, с QM_AS400 на QM_HPUX. Доступ к запуску приложений на AS400 временно закрыт. Но WebSphere MQ работает. Самое простое решение (рис.7.11) с сервера WindowsNT направляем необходимую "пачку" сообщений на AS400 в локальную удаленную очередь (remote queue), нацеленную на HP_UNIX. Этот же прием может использоваться, если доступ к менеджеру QM_HPUX открыт только с определенного IP адреса.
Рис. 7.11. Перенаправление потоков
"Вечный двигатель"
Этот прием весьма полезен при тестировании интерфейсов для проверки стабильности и надежности работы программ. Схема "вечного двигателя" изображена на рис. 7.12. В очереди Remote Queue rq1 на сервере WindowsNT в качестве параметра Remote Queue Name указывается rq2, а на сервере HP_UNIX в очереди Remote Queue rq2 соответственно rq1.
Рис. 7.12. "Вечный двигатель"
И еще один прием, точнее святая обязанность администратора WebSphere MQ, это документирование интерфейсов. Весьма удобно иметь документированные интерфейсы в графическом виде, и программных средств для этого более чем достаточно (Visio, Bpwin и т.д.). Но по мере сложности интерфейсов их графическое представление становится не наглядным. В этом случае может быть рекомендован Excel, с помощью которого в колонках таблиц прописываются параметры настройки интерфейсов.
По мере возрастания количества интерфейсов, менеджеров и их объектов может возникнуть ситуация, когда администратор WebSphere MQ по названию объекта не сможет определить его сущность. Во избежание этого рекомендуется с самого начала разработать некоторые правила, по которым следует называть все объекты на разных менеджерах. Например, если простые локальные очереди (local queue) будут оканчиваться на .Q, трансмиссионные (transmission queue) на .TQ, локальные удаленные (remote queue) на .RQ, каналы на .CH, процессы на .P и так далее, то по окончанию сразу можно определить тип объекта. То же касается направления передачи и сущности передаваемых сообщений. Например, надо передать курсы валют из системы ABS1 в систему ABS2.
Создаваемые объекты в системе ABS1 можно назвать:
ABS1_ ABS2_CV.RQ – локальная удаленная очередь;
ABS1_ ABS2_CV.TQ – локальная трансмиссионная очередь;
ABS1_ ABS2_CV.CH – канал отправитель.
В системе ABS2:
ABS1_ ABS2_CV.Q – локальная очередь;
ABS1_ ABS2_CV.CH – канал получатель.
Кроме всего прочего, если производительность интерфейса передачи данных позволяет помимо обработки сообщений еще и создавать файлы журнала прохождения и обработки сообщений на каждом участке, то наличие таких файлов, содержащих как минимум время и мнемонику сообщений, а как максимум и их текст, существенно облегчает работу по поиску и устранению неисправностей.
Вопросы производительности рассматривались в той или иной мере в предыдущих лекциях. Подводя итог, можно разделить проблемы производительности на две группы, одна из которых связана со скоростью передачи данных в сети, а другая, связана со скоростью помещения и извлечения сообщений из очередей.
В первой группе решающую роль играет собственно, сетевое оборудование и качество линий связи. Скорость передачи данных от менеджера до менеджера сопоставима со скоростью передачи данных в сети. Ко второй группе можно отнести следующие факторы.
Серверное оборудование – чем мощнее сервера, тем быстрее будет работать программное обеспечение.
Размеры баз данных – чем больше база, тем дольше выполняются запросы.
Алгоритмы обработки сообщений – если требуется просто вставить запись в таблицу, то это может быть относительно высокая скорость, а если требуется выполнение операторов SELECT и проверка условий, на основе которых принимается решение о добавлении или изменении записи, то скорость обработки сообщений уменьшается.
Программное обеспечение – корректно написанная программа работает быстрее, к тому же выбор языка программирования играет важную роль. Замечено, что один и тот же алгоритм, реализованный на C и Visual Basic, дает существенно разные результаты. Например, простое перекладывание persistent сообщений размером 1Кб из очереди в очередь на одном и том же менеджере (NT платформа, процессор Pentium IV с тактовой частотой 1.8 ГГц) с помощью программы, написанной на С, дает результат 400 сообщений в секунду, а с помощью программы на Visual Basic только 140.
Тип хранения сообщений в очереди – сообщения persistent обрабатываются медленнее, чем not persistent. Not persistent сообщения из предыдущего примера перекладывались со скоростями 1000 и 200 сообщений в секунду, соответственно.
Наличие механизмов шифрования и сертификации также влияет на скорость обработки сообщений. Так использование SSL механизма может отнять до 10% производительности в зависимости от длины ключа и алгоритма шифрования данных.
Вопросы производительности
Кроме выяснения причин ошибок передачи и их устранения, администратор WebSphere MQ должен планировать и рассчитывать схемы передачи данных от одной платформы до другой. Рассмотрим простой пример передачи сообщения, содержащего информацию из строки таблицы из одной базы данных DataBase1 в другую базу DataBase2, расположенную на другой платформе. Интерфейс передачи данных можно разбить на три части (рис. 7.9).
Рис. 7.9. Схема интерфейса передачи данных
Первая часть – программа А, помещающая сообщения в исходящую очередь RQ1, вторая – передача сообщений от одного менеджера очередей к другому в очередь назначения Q2, третья – программа B, помещающая сообщения из очереди назначения Q2 в таблицу базы данных.
В данной схеме нужно учитывать, что скорость разбора сообщений из очереди назначения Q2 и помещения их в DataBase2 (участок 3) должна быть больше скорости поступления сообщений в эту очередь. Если же сообщения генерируются в исходящую очередь из базы DataBase1 не линейно, то необходимо учитывать характер нелинейности и возможные "узкие" места интерфейса. В любом случае не следует допускать переполнения очередей.
Часто встречаются задачи, в которых требуется при изменении информации в одной системе передать произошедшие изменения в другие системы, причем формат изменяемых данных на разных платформах может иметь различный вид. При этом обработку информации целесообразно сосредоточить в одном месте, так как алгоритмы преобразования данных из DataBase1 в DataBase2, DataBase3 и т.д. очень похожи и имеют много общего, а часто являются подмножествами друг друга. В этом случае мы имеем интерфейс передачи данных с централизованной обработкой сообщений, схема которого показана на рис.7.10.
Рис. 7.10. Схема интерфейса с централизованной обработкой сообщений
В качестве инструментального средства для центра обработки сообщений рекомендуется Брокер сообщений WebSphere BI Message Broker. Это достаточно эффективный инструмент, являющийся интегрированной средой для визуального проектирования программ обработки сообщений. При проектировании более сложных, разветвленных потоков передачи и распространения информации, которая на пути от источника к приемнику может меняться и дополняться, следует также учитывать производительность всех точек входа и выхода сообщений и соизмерять скорости выгрузки сообщений со скоростью их передачи и обработки.
Приведем еще несколько приемов настройки и тестирования интерфейсов.
Интеграция приложений на основе WebSphere MQ
Дополнительные функции WebSphere MQ
Одним из важнейших приемов прикладного программирования для WebSphere MQ является использование транзакций, аналогичных транзакциям в базах данных. С помощью функций MQBEGIN, MQCMIT, MQBACK можно открыть транзакцию, завершить транзакцию успешно и откатить транзакцию, соответственно. В этом механизме прослеживается полная аналогия с транзакциями в базах данных. Программирование с использованием WebSphere MQ транзакций позволяет создавать надежные программы.Синтаксис:
MQBEGIN (Hconn, BeginOptions, CompCode, Reason)
где:
| Hconn | - | идентификатор связи (connection handle) с менеджером очередей |
| BeginOptions | - | опции MQBEGIN |
| CompCode | - | код завершения |
| Reason | - | код ошибки, детализирующий код завершения. |
Здесь BeginOptions дает ссылку на структуру MQBO (Begin options), поля которой показаны в таблице 8.6
| StrucId | MQCHAR4 | Идентификатор структуры | MQBO_STRUC_ID | 'BObb' |
| Version | MQLONG | Номер версии структуры | MQBO_VERSION_1 | 1 |
| Options | MQLONG | Опции для управления MQBO | MQBO_NONE | 0 |
На языке С макропеременная MQBO_DEFAULT содержит значения, приведенные в табл.8.6, и может быть использована в тексте следующим образом: MQBO MyBO = {MQBO_DEFAULT};
Синтаксис:
MQCMIT (Hconn, CompCode, Reason)
Комментарии в данном случае излишни.
Синтаксис:
MQBACK (Hconn, CompCode, Reason)
Работа функций MQBEGIN, MQCMIT и MQBACK будет на примере продемонстрирована в лекции 9.
Следующие группы функций позволяют считывать и модифицировать атрибуты WebSphere MQ объектов, а также предоставляют дополнительный сервис.
Синтаксис:
MQINQ (Hconn, Hobj, SelectorCount, Selectors, IntAttrCount, IntAttrs, CharAttrLength, CharAttrs, CompCode, Reason)
где:
| Hconn | - | идентификатор связи с менеджером очередей, полученный от MQCONN |
| Hobj | - | идентификатор объекта, полученный от MQOPEN |
| SelectorCount | - | Счетчик атрибутов, которые должны быть извлечены (от 0 до 256) |
| Selectors | - | Массив значений атрибутов, т.е. чисел или символов, которые должны быть извлечены |
| IntAttrCount | - | Счетчик цифровых атрибутов |
| IntAttrs | - | Массив цифровых атрибутов |
| CharAttrLength | - | Длина буфера символьных атрибутов |
| CharAttrs | - | Буфер значений символьных атрибутов |
| CompCode | - | код завершения |
| Reason | - | код ошибки, детализирующий код завершения. |
Комментарии. Буфер CharAttrs должен содержать значения символьных атрибутов для записи в том же порядке, как перечислены атрибуты в Selectors. Имена устанавливаемых атрибутов приведены в главе "MQSET – Set object attributes" [14].
Синтаксис:
MQCONNХ (QMgrName, ConnectOpts, Hconn, CompCode, Reason)
Функция MQCONNХ отличается от MQCONN наличием параметра ConnectOpts для контроля процесса подключения к менеджеру очередей и позволяет установить дополнительные опции. Опции MQCNO_STANDARD_BINDING и MQCNO_FASTPATH_BINDING служат для стандартного или быстрого установления связи. Опции MQCNO_HANDLE_SHARE_NONE, MQCNO_HANDLE_SHARE_BLOCK, MQCNO_HANDLE_SHARE_NO_BLOCK позволяют осуществлять управление идентификаторами связи при работе с разными процессами (threads).
Опции SSLConfigPtr и SSLConfigOffset используются, когда приложение осуществляет вызов MQCONNХ через WebSphere MQ клиента по протоколу TCP/IP. Более подробно эти опции описаны в главе "MQCNO – Connect options" [14].
Синтаксис:
MQPUT1 (Hconn, ObjDesc, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason)
Как следствие такого определения функции вместо параметра Hobj для MQPUT в MQPUT1 используется параметр ObjDesc, как и в функции MQOPEN.
На этом обзор основных и дополнительных функций WebSphere MQ закончен. Теперь можно начинать писать первые приложения для WebSphere MQ, что и будет сделано в следующей лекции.
В заключении следует отметить, что разработчикам приложений необходимо выбирать язык программирования исходя из решаемой задачи и требований на создаваемое ПО. Если приложение должно работать с WebSphere MQ в режиме промышленной эксплуатации при достаточно высоких требованиях на производительность, то рекомендуется использовать С, С++. Если приложение работает с WebSphere MQ в тестовом режиме без ограничений на производительность, то вполне подойдут Visual Basic 6.0 или Power Builder 6.0. Известны случаи, когда приложение, написанное на Visual Basic 6.0 или Power Builder 6.0 и работающее постоянно с WebSphere MQ, начинало наращивать используемую оперативную память, и разработчики этих программ не могли понять причину ошибки и устранить ее. Приложение, написанное на С++ и реализующее тот же алгоритм, не имеет подобного дефекта. Красивые интерфейсы при работе с WebSphere MQ требуются не так часто. Кроме того, следует отметить, что приложение на C/С++ обеспечивает обработку более 400 Persistent сообщений/секунду при длине сообщения 1Кбайт, в то время как приложение с тем же алгоритмом обработки на Visual Basic - не более 150 сообщений/секунду на компьютере INTEL Pentium 1.8Ггц. Все это объясняет тот факт, что в данной книге примеры программ даются на языке С.
| © 2003-2007 INTUIT.ru. Все права защищены. |
Общие сведения о разработке приложений для WebSphere MQ
В большинстве приложений, работающих с WebSphere MQ, решаются такие задачи как: чтение сообщений из базы данных (БД) и запись их в очередь; чтение сообщений из очереди и запись их в БД; и то и другое одновременно. В более редких случаях, например, для задач мониторинга осуществляется чтение параметров объектов WebSphere MQ в частности Current Depth, Channel Status, Message Count, Last Message Date/Time и т.п.Для задач чтения/записи сообщений в очередь ведется работа непосредственно с сообщениями. На рис.8.1 показана структура одного из таких сообщений.
Рис. 8.1. Структура сообщения
Заголовок сообщения (Message Header) несет в себе служебную информацию: идентификационный номер сообщения (Message ID); идентификатор пользователя, пославшего сообщение; формат, длину, кодировку, тип сообщения, дату и время отправки и т.д. Данные в сообщении (Message Data) на уровне приложений разделяются на поля. В спецификации приложений записывается структура сообщения, например, в табл.8.1.
| Name | 50 | Для заполнения поля Account_Name таблицы Account |
| Account | 32 | Для заполнения поля Account таблицы Account |
| ClientNo | 32 | Для заполнения поля ClientNo таблицы Account |
| Detail | 4 | Для заполнения поля Detail таблицы Account |
| Account_Date | 10 | Дата в формате 'YYYY-MM-DD' для заполнения поля Account_Date таблицы Account |
| Account_Time | 8 | Время в формате 'HH-MM-SS' для заполнения поля Account_Time таблицы Account |
| Comment | 150 | Для заполнения поля Comment таблицы Account |
В теле сообщения поля не имеют имен и идут в порядке перечисления в таблице 8.1. без разделителей (разделители могут быть использованы, но тогда длина сообщения увеличится). Числа (Integer, Long) записываются в символьном формате.
По WebSphere MQ интерфейсу (канал и соответствующие очереди) могут передаваться сообщения одного или нескольких типов, например, информация о клиентах, счетах и проводках. Для обработки сообщения большое значение имеет поле заголовка MSGTYPE, определяющее тип сообщения. Каждому типу сообщения соответствует своя структура данных сообщения (Message Data). По типу сообщения программа определяет, по какой ветви программы осуществлять разбор сообщения. С одной стороны, не целесообразно увеличивать число интерфейсов и, соответственно, число WebSphere MQ объектов и обрабатывающих программ, однако практические неудобства могут сказаться, если число WebSphere MQ объектов перевалит за несколько сотен и они все будут использоваться одновременно на недостаточно мощной технике. С другой стороны, программирование и внедрение программ облегчается, если на один тип сообщения создается один интерфейс и одна программа. Оптимальное решение следует искать где-то посередине между этими двумя подходами. К вопросам унификации интерфейсов следует вернуться (это будет сделано при рассмотрении одновременной работы WebSphere MQ и баз данных), так как создание и сопровождение нескольких сотен похожих программ для работы WebSphere MQ может вызвать серьезные затруднения.
Основу для программирования приложений, работающих с WebSphere MQ, предоставляет интерфейс очередей сообщений MQI (Message Queue Interface).
Приложения для работы с WebSphere MQ, создаваемые пользователем, могут использовать следующие группы функций MQI:
Таким образом, обобщенная структура программы для работы с WebSphere MQ на уровне блоков может быть представлена в виде следующей последовательности псевдокода:
| Блок 1 MQCONN |
| Блок 2 MQOPEN |
| Блок 3 MQBEGIN |
| Блок 4 MQGET |
| Блок 5 SQL UPDATE, SQL SELECT |
| Блок 6 MQPUT |
| Блок 7 Если нет ошибок - MQCMIT, в противном случае MQBACK |
| Блок 8 MQCLOSE |
| Блок 9 MQDISC |
Для программирования приложений, работающих с WebSphere MQ, предлагается инструментарий на различных языках: C (для всех платформ), C++ (для большинства операционных систем), Visual Basic (для систем Windows), COBOL, Assembler (для мэйн-фреймов ИБМ с операционной системой z/OS), RPG, PL/I (для систем с z/OS, OS/2 Warp, VSE/ESA, Windows), TAL (для систем с Compaq NonStop Kernel) и другие средства.
В WebSphere MQ для приложений на C++ в среде Windows следует редактировать (линковать) разрабатываемую программу с библиотекой MQI в дополнение к библиотекам операционной системы:
В качестве заголовочных файлов следует использовать cmqc.h или cmqcfc.h
Библиотека MQI обеспечивает реализацию функций WebSphere MQ. Список библиотек на других платформах, необходимых для разработки приложений на основе WMQ, можно найти в документации.
Следует упомянуть об интерфейсе приложений для передачи сообщений AMI (Application Messaging Interface), который является более простым и высокоуровневым интерфейсом, чем MQI. И хотя AMI имеет некоторые ограничения по сравнению с MQI, его функции достаточно эффективны для большинства пользователей. AMI поддерживает два типа моделей для программирования приложений: точка-точка, издатель-подписчик. Интерфейс AMI существует для языков C, C++ и Java, работающих в операционных системах: OS/400, AIX, HP-UX, Solaris, Microsoft Windows и z/OS.
В дальнейшем при описании функций интерфейса MQI будут использованы общие для всех функций два типа параметров: идентификатор (handle) и код возврата (return сode). При подключении к менеджеру очередей должен быть создан уникальный идентификатор этого менеджера для данного приложения, который называется идентификатором связи Hconn (connection handle). Идентификатор Hconn возвращается функциями MQCONN или MQCONNХ и передается во все другие функции как входной параметр. При работе с объектом WebSphere MQ должен также существовать уникальный идентификатор, называемый идентификатором объекта (object Handle). Этот идентификатор определяется функций MQOPEN при открытии объекта и возвращается как Hobj. Программа передает идентификатор объекта как входной параметр при вызове функций MQPUT, MQGET, MQINQ, MQSET или MQCLOSE.
Код завершения (completion code) и код ошибки (reason code) возвращаются как выходные параметры в каждой функции. Совместно они называются кодами возврата (return codes) и показывают результат выполнения функции. Код завершения возвращается либо как MQCC_OK или MQCC_FAILED, отображая успешное или ошибочное выполнение функции, соответственно. Иногда возвращается промежуточное значение MQCC_WARNING как предупреждение о неполном завершении. MQCC_OK всегда соответствует Reason code = 0. MQCC_WARNING может сопутствовать, например, Reason code = 2002, это говорит о том, что приложение уже подключено. MQCC_FAILED обязательно имеет детализацию, например: Reason code = 2058 - менеджер с данным именем неизвестен или недоступен, Reason code = 2035 - нет прав доступа и т.д. Программа может и должна использовать код ошибки в процессе обработки. Например, при определенном коде ошибки программа может выдать сообщение пользователю с предложением изменить входные данные и после этого повторить вызов функции либо вернуть сообщение пользователю. Коды возврата подробно описаны в книге WebSphere MQ Messages [7].
Основные функции WebSphere MQ
Синтаксис:
MQCONN (QmgrName, Hconn, CompCode, Reason)
где:
| QmgrNam | - | имя менеджера очередей, к которому производиться подключение (латинские буквы, цифры, символы "_", "/", ".", "%" ). |
| Hconn | - | идентификатор связи (connection handle) с менеджером очередей |
| CompCode | - | код завершения, принимающий одно из трех значений: MQCC_OK, MQCC_WARNING, MQCC_FAILED |
| Reason | - | код ошибки, детализирующий код завершения. |
Результат работы функции – установление связи с менеджером очередей и возвращение уникального идентификатора связи Hconn с менеджером. Имя QmgrNam может быть опущено (строка со значением Null или пробел), тогда обращение к менеджеру очередей на данном компьютере происходит по умолчанию. Одно из основных назначений функции – проверка авторизации пользователя (приложение работает под определенным пользователем с идентификатором userid, который может быть не авторизован для работы с данным менеджером или его объектами).
Синтаксис:
MQOPEN (Hconn, ObjDesc, Options, Hobj, CompCode, Reason)
где:
| Hconn | - | идентификатор связи (connection handle) с менеджером очередей |
| ObjDesc | - | описание объекта MQOD |
| Options | - | опции объекта MQOO |
| Hobj | - | идентификатор связи с объектом |
| CompCode | - | код завершения, принимающий одно из трех значений: MQCC_OK – успешное завершение, MQCC_WARNING – предупреждение, MQCC_FAILED – ошибочный вызов |
| Reason | - | код ошибки, детализирующий код завершения. |
Результат работы функции – возвращение уникального идентификатора связи Hobj с "открытым" объектом WebSphere MQ, то есть очередью, с которой установлена связь. Описание объекта MQOD – это ссылка на структуру объекта из библиотеки WebSphere MQ. Структура MQOD представлена в таблице 8.2.
Опции объекта (переменная MQLONG): MQOO_BROWSE* – просмотр объекта, MQOO_INPUT* – объект открыт для помещения сообщений, MQOO_OUTPUT – объект открыт для извлечения сообщений, MQOO_INQUIRE - объект открыт для извлечения атрибутов, MQOO_SET - объект открыт для изменения атрибутов и др. Опции объекта со звездочками задаются, как правило, в виде развернутых констант:
Описание всех опций MQOO дано в главе "MQOPEN – Open object" [14] и объекта MQOD - в главе "MQOD – Object descriptor" [14]. Как правило, значений опций по умолчанию для MQOPEN вполне достаточно для программирования стандартных приложений для WebSphere MQ.
| StrucId | MQCHAR4 | MQOD_STRUC_ID | 'ODbb' |
| Version | MQLONG | MQOD_VERSION_1 | 1 |
| ObjectType | MQLONG | MQOT_Q | 1 |
| ObjectName | MQCHAR48 | Нет | Строка со значением Null или пробел |
| ObjectQMgrName | MQCHAR48 | Нет | Строка со значением Null или пробел |
| DynamicQName | MQCHAR48 | Нет | 'CSQ.*' на z/OS; 'AMQ.*' в противном случае |
| AlternateUserId | MQCHAR12 | Нет | Строка со значением Null или пробел |
| RecsPresent | MQLONG | Нет | 0 |
| KnownDestCount | MQLONG | Нет | 0 |
| UnknownDestCount | MQLONG | Нет | 0 |
| InvalidDestCount | MQLONG | Нет | 0 |
| ObjectRecOffset | MQLONG | Нет | 0 |
| ResponseRecOffset | MQLONG | Нет | 0 |
| ObjectRecPtr None | MQPTR | Нет | Указатель со значением Null |
| ResponseRecPtr | MQPTR | Нет | Указатель со значением Null |
| AlternateSecurityId | MQBYTE40 | MQSID_NONE | Nulls |
| ResolvedQName | MQCHAR48 | Нет | Строка со значением Null или пробел |
| ResolvedQMgrName | MQCHAR48 | Нет | Строка со значением Null или пробел |
Hconn и Hobj – это идентификаторы, полученные от MQCONN и MQOPEN, соответственно.
Описание сообщения MQMD – это ссылка на структуру объекта из библиотеки WebSphere MQ. Эта структура записывается следующим образом (табл.8.3).
| StrucId | MQCHAR4 | MQMD_STRUC_ID | 'MDbb' |
| Version | MQLONG | MQMD_VERSION_1 | 1 |
| Report | MQLONG | MQRO_NONE | 0 |
| MsgType | MQLONG | MQMT_DATAGRAM | 8 |
| Expiry | MQLONG | MQEI_UNLIMITED | MQEI_UNLIMITED |
| Feedback | MQLONG | MQFB_NONE | 0 |
| Encoding | MQLONG | MQENC_NATIVE | В зависимости от среды |
| CodedCharSetId | MQLONG | MQCCSI_Q_MGR | 0 |
| Format | MQCHAR8 | MQFMT_NONE | Пробел |
| Priority | MQLONG | MQPRI_PRIORITY_AS_Q_DEF | -1 |
| Persistence | MQLONG | MQPER_PERSISTENCE_AS_Q_DEF | 2 |
| MsgId | MQBYTE24 | MQMI_NONE | Nulls |
| CorrelId | MQBYTE24 | MQCI_NONE | Nulls |
| BackoutCount | MQLONG | Нет | 0 |
| ReplyToQ | MQCHAR48 | Нет | Строка со значением Null или пробел |
| ReplyToQMgr | MQCHAR48 | Нет | Строка со значением Null или пробел |
| UserIdentifier | MQCHAR12 | Нет | Строка со значением Null или пробел |
| AccountingToken | MQBYTE32 | MQACT_NONE | Nulls |
| ApplIdentityData | MQBYTE32 | Нет | Строка со значением Null или пробел |
| PutApplType | MQLONG | MQAT_NO_CONTEXT | 0 |
| PutApplName | MQCHAR28 | Нет | Строка со значением Null или пробел |
| PutDate | MQCHAR8 | Нет | Строка со значением Null или пробел |
| PutTime | MQCHAR8 | Нет | Строка со значением Null или пробел |
| ApplOriginData | MQCHAR4 | Нет | Строка со значением Null или пробел |
| GroupId | MQBYTE24 | MQGI_NONE | Nulls |
| MsgSeqNumber | MQLONG | Нет | 1 |
| Offset | MQLONG | Нет | 0 |
| MsgFlags | MQLONG | MQMF_NONE | 0 |
| OriginalLength | MQLONG | MQOL_UNDEFINED | -1 |
GetMsgOpts – опции для функции MQGET - MQGMO (Get-message options), поля структуры которой приведены в таблице 8.4. Наиболее часто используемые опции для управления MQGET:
Все опции MQGMO даны в главе "MQGET – Get message" [14].
BufferLength – длина в байтах области буфера Buffer, в который считывается сообщение (переменная типа MQLONG). Максимальная длина сообщений 100Мбт, длина по умолчанию 4Мбт, реальная длина большинства сообщений не более 10Кбт.
Buffer - буфер, в который считывается сообщение.
DataLength – длина сообщения в байтах (переменная MQLONG).
Если DataLength для реального сообщения больше BufferLength, то часть сообщения может быть потеряна в зависимости от опции MQGMO_ACCEPT_TRUNCATED_MSG.
CompCode, Reason – это стандартные возвращаемые параметры, упомянутые выше и не требующие детальных пояснений.
| StrucId | MQCHAR4 | Идентификатор структуры | MQGMO_STRUC_ID | 'GMOb' |
| Version | MQLONG | Номер версии структуры | MQGMO_VERSION_1 | 1 |
| Options | MQLONG | Опции для управления MQGET | MQGMO_NO_WAIT | 0 |
| WaitInterval | MQLONG | Интервал ожидания (Wait interval) WaitInterval | None | 0 |
| Signal1 | MQLONG | Сигнал | Нет | Указатель Null на z/OS; 0 в ост. случаях |
| Signal2 | MQLONG | Идентификатор сигнала | Нет | 0 |
| ResolvedQName | MQCHAR48 | Разрешенное имя очереди назначения (destination queue) | Нет | Строка string или пробел |
| MatchOptions | MQLONG | Опции управления критериями выбора, используемыми MQGET | MQMO_MATCH_MSG_ID + MQMO_MATCH_CORREL_ID | 3 |
| GroupStatus | MQCHAR | Флаг, индицирующий, что извлеченное сообщение находиться в группе сообщений | MQGS_NOT_IN_GROUP | 'b' |
| SegmentStatus | MQCHAR | Флаг, индицирующий, что извлеченное сообщение является сегментом логического сообщения | MQSS_NOT_A_SEGMENT | 'b' |
| Segmentation | MQCHAR | Флаг, индицирующий, что допускается дальнейшая сегментация для извлеченного сообщения | MQSEG_INHIBITED | 'b' |
| Reserved1 | MQCHAR | Резервное | Нет | 'b' |
| MsgToken | MQBYTE16 | Маркер сообщения (Message token) | MQMTOK_NONE | Nulls |
| ReturnedLength | MQLONG | Возвращаемая длина сообщения в байтах | MQRL_UNDEFINED | -1 |
Синтаксис:
MQPUT (Hconn, Hobj, MsgDesc, PutMsgOpts, BufferLength, Buffer, CompCode, Reason)
где:
| Hconn | - | идентификатор связи с менеджером очередей, полученный от MQCONN |
| Hobj | - | идентификатор объекта, полученный от MQOPEN |
| MsgDesc | - | описание сообщения MQMD |
| PutMsgOpts | - | опции MQPMO для записи сообщений |
| BufferLength | - | длина буфера Buffer, откуда пишется сообщение. Значение 0 является действительным и показывает, что сообщение не содержит данных. |
| Buffer | - | буфер, из которого пишется сообщение |
| CompCode | - | код завершения, принимающий одно из трех значений: MQCC_OK, MQCC_WARNING, MQCC_FAILED |
| Reason | - | код ошибки, детализирующий код завершения. |
| StrucId | MQCHAR4 | Идентификатор структуры | MQPMO_STRUC_ID | 'PMOb' |
| Version | MQLONG | Номер версии структуры | MQPMO_VERSION_1 | 1 |
| Options | MQLONG | Опции для управления MQPUT и MQPUT1 | MQPMO_NONE | 0 |
| Timeout | MQLONG | Зарезервировано | Нет | -1 |
| Context | MQHOBJ | Идентификатор объекта входной очереди | Нет | 0 |
| KnownDestCount | MQLONG | Число сообщений, посланное успешно в локальную очередь | Нет | 0 |
| UnknownDestCount | MQLONG | Число сообщений, посланное успешно в удаленную очередь | Нет | 0 |
| InvalidDestCount | MQLONG | Число сообщений, которые возможно не посланы | Нет | 0 |
| ResolvedQName | MQCHAR48 | Разрешенное имя очереди назначения | Нет | Строка Null или пробел |
| ResolvedQMgrName | MQCHAR48 | Разрешенное имя менеджера назначения | Нет | Строка Null или пробел |
| RecsPresent | MQLONG | Число записей помещенных сообщений или ответных записей в настоящее время | Нет | 0 |
| PutMsgRecFields | MQLONG | Флаг, индицирующий, что MQPMR поле присутствует | MQPMRF_NONE | 0 |
| PutMsgRecOffset | MQLONG | Погашение записи первого помещенного сообщения с момента старта MQPMO | Нет | 0 |
| ResponseRecOffset | MQLONG | Погашение записи первого ответа с момента старта MQPMO | Нет | 0 |
| PutMsgRecPtr | MQPTR | Адрес записи первого помещенного в очередь сообщения | Нет | Указатель Null |
| ResponseRecPtr | MQPTR | Адрес записи первого ответа | Нет | Указатель Null |
Среди опций для управления MQPUT следует назвать:
Полный список опций MQPMO дан в главе "MQPUT – Put message" [14].
Функция MQPUT может положить сообщение как в локальную (local queue), так и в удаленную очередь (remote queue). MQGET считывает сообщения только из локальной очереди локального менеджера очередей, но не может читать сообщения на удаленном менеджере.
Синтаксис:
MQCLOSE (Hconn, Hobj, Options, CompCode, Reason)
где:
| Hconn | - | идентификатор связи (connection handle) с менеджером очередей |
| Hobj | - | идентификатор связи с объектом |
| ObjDesc | - | описание объекта MQOD |
| Options | - | опции объекта |
| CompCode | - | код завершения |
| Reason | - | код ошибки, детализирующий код завершения. |
Синтаксис:
MQDISC (Hconn, CompCode, Reason)
где:
| Hconn | - | идентификатор связи (connection handle) с менеджером очередей |
| CompCode | - | код завершения |
| Reason | - | код ошибки |
Для работы приложений в условиях промышленной эксплуатации необходимо использовать дополнительные функции WebSphere MQ.
Интеграция приложений на основе WebSphere MQ
Программа rewriter (модель "один к одному")
Первая программа будет достаточно простая и реализует так называемую модель "один к одному" или "точка-точка". Эта программа предназначена для чтения сообщений из очереди 1, записи их в очередь 2 и лог-файл на диске. Эта программа имеет практическое значение. Достаточно часто необходимо иметь файл переданных сообщений за определенный период времени, чтобы быстро ответить на вопрос "Было ли передано сообщение с такими идентификационными параметрами в теле сообщения:…"? WebSphere MQ сохраняет persistent сообщения на диске, но эти лог-файлы малопонятны, предназначены для восстановления сообщений при сбоях и достаточно быстро перезаписываются менеджерами очередей при значение параметра logging = circular (по умолчанию) и больших потоках сообщений (logging = linear рекомендуется только для систем промышленной эксплуатации и в этом случае администратор WebSphere MQ должен заботиться о том, чтобы лог-файлы не "замусорили" весь жесткий диск). Поэтому наша программа может быть достаточно полезной.Автору приходилось сталкиваться с "плохим" стилем программирования, когда параметры программы "зашиваются" в текст. Даже в учебных курсах этого следует избегать, несмотря на некоторое усложнение программ. В наших программах мы будем использовать простые файлы инициализации, чтобы избежать этой ошибки. Назовем нашу программу rewriter.exe и файл инициализации rewriter.ini, в котором 1-я строка – имя очереди для чтения, 2-я строка – имя очереди для записи, 3-я строка – имя лог-файла, как показано ниже.
QUEUE_INPUT QUEUE_OUTPUT C:\TEMP\rewriter.log
Разрабатываемая программа может быть представлена в следующей последовательности псевдокода:
MQCONN MQOPEN --> цикл чтения сообщений | (на основе gmo.WaitInterval): | MQGET | MQPUT |-- конец цикла MQCLOSE MQDISC
Ниже приводится листинг программы rewriter.cpp для Microsoft Visual C++ ver.6.0. Не забудьте добавить mqm.Lib в Project => Settings => Link и обратиться к документации [15], [16], [17] в случае проблем с программированием.
Листинг 9.1. Rewriter C program pass messages to output queue (html, txt)
В данной версии мы выходим из цикла программы по опции gmo.WaitInterval = 3000, когда ожидаем сообщение в очереди в течении 3 сек, а его там нет (опция gmo.WaitInterval работает быстрее, чем если бы мы опрашивали очередь по собственному временному циклу). Другой вариант программы может быть таким. Задаем gmo.WaitInterval = MQWI_UNLIMITED; что соответствует gmo.WaitInterval= -1. Программа будет крутиться "бесконечно" до тех пор, пока мы не остановим её принудительно, например, нажатием клавиш CNTRL_C (стандартный останов). В этом случае нужно добавить обработчик прерываний по нажатию CNTRL_C потому, что при таком выходе объекты очереди останутся не закрытыми и идентификаторы объектов окажутся "зависшими" в виртуальной памяти компьютера. А это может привести к тому, что при повторном запуске программы эти "зависшие" идентификаторы будут мешать нормальному функционированию программы. Во втором варианте открытие и закрытие лог-файла необходимо также делать в обработчике прерываний или после каждой команды MQPUT, в противном случае лог-файл не будет формироваться. Следует отметить, что размер массива buffer ограничивает длину сообщения 8Кб и при появлении сообщений большей длины следует увеличить размер буфера.
Программа rewriter.exe работает достаточно быстро и сравнительные скорости работы данного алгоритма при длине сообщения 1Кб на компьютере INTEL Pentium 1.8Ггц приведены в таблице ниже.
| С++ | 1000 сооб/сек | 400 сооб/сек |
| Visual Basic 6.0 | 200 сооб/сек | 140 сооб/сек |
Возвращаясь к вопросу о стилях программирования, следует отметить, что обработка кода ошибки является обязательным атрибутом качественного программирования и об этом не следует забывать. В нашей программе дается предупредительное сообщение и делается выход из программы. Если этого не сделать, то простая описка в rewriter.ini файле приведет к зависанию программы и мучительному поиску причин такого зависания, не говоря о других более сложных ситуациях, например, когда очередь открыта эксклюзивно другим приложением.
Для версии программы gmo.WaitInterval = MQWI_UNLIMITED полезно сделать вывод на экран передаваемых сообщений, чтобы наблюдать динамику работы созданного интерфейса. Таких улучшений может быть достаточно много и мы рассмотрим две достаточно полезные модификации.
Программа rewriter может вызываться как MQSeries-триггер. Для этого параметры можно задать следующим образом. Входная очередь – это очередь, на которой определен триггеринг. Выходная очередь – это User Data в триггерном процессе и имя лог файла – это Environment Date в триггерном процессе. В этом случае код в начале программы будет такой.
/* Код для вызова rewriter.exe как MQSeries-триггер */ int main(int argc, char **argv) { if (argc > 1) {trig = (MQTMC2*)argv[1]; strncpy(odG.ObjectName, trig->QName, MQ_Q_NAME_LENGTH); strncpy(queue1, trig->QName, MQ_Q_NAME_LENGTH); strncpy(QManager, trig->QMgrName, MQ_Q_MGR_NAME_LENGTH); strncpy(odP.ObjectName, trig->UserData, MQ_PROCESS_USER_DATA_LENGTH); strncpy(queue2, trig->UserData, MQ_PROCESS_USER_DATA_LENGTH); strncpy(logfilename2, trig->EnvData, 48); }
Возможная модификация этого варианта - программа rewriter может вызываться с передачей параметров через командную строку и эту модификацию читатель может проделать самостоятельно.
Можно сделать программу mqsplitter.exe на разных языках, например, на Visual Basic 6.0 с интерфейсом, показанным на рис.9.1, и сравнить производительность программ на разных языках, реализующих один и тот же алгоритм. Такая задача будет хорошим лабораторным практикумом.
увеличить изображение
Рис. 9.1. Интерфейс программы mqsplitter на VB6
Модификацию программы mqsplitter.exe читателю предлагается сделать самостоятельно и одновременно проверить идею создания "вечного двигателя". Для создания "вечного двигателя" понадобиться изменить исходный mqsplitter.ini файл следующим образом:
| QUEUE_INPUT |
| QUEUE_OUTPUT1 |
| QUEUE_OUTPUT2 |
| C:\TEMP\ mqsplitter.log |
Программа rewriter.exe работает достаточно быстро и сравнительные скорости работы данного алгоритма при длине сообщения 1Кб на компьютере INTEL Pentium 1.8Ггц приведены в таблице ниже.
| С++ | 1000 сооб/сек | 400 сооб/сек |
| Visual Basic 6.0 | 200 сооб/сек | 140 сооб/сек |
Возвращаясь к вопросу о стилях программирования, следует отметить, что обработка кода ошибки является обязательным атрибутом качественного программирования и об этом не следует забывать. В нашей программе дается предупредительное сообщение и делается выход из программы. Если этого не сделать, то простая описка в rewriter.ini файле приведет к зависанию программы и мучительному поиску причин такого зависания, не говоря о других более сложных ситуациях, например, когда очередь открыта эксклюзивно другим приложением.
Для версии программы gmo.WaitInterval = MQWI_UNLIMITED полезно сделать вывод на экран передаваемых сообщений, чтобы наблюдать динамику работы созданного интерфейса. Таких улучшений может быть достаточно много и мы рассмотрим две достаточно полезные модификации.
Программа rewriter может вызываться как MQSeries-триггер. Для этого параметры можно задать следующим образом. Входная очередь – это очередь, на которой определен триггеринг. Выходная очередь – это User Data в триггерном процессе и имя лог файла – это Environment Date в триггерном процессе. В этом случае код в начале программы будет такой.
/* Код для вызова rewriter.exe как MQSeries-триггер */ int main(int argc, char **argv) { if (argc > 1) {trig = (MQTMC2*)argv[1]; strncpy(odG.ObjectName, trig->QName, MQ_Q_NAME_LENGTH); strncpy(queue1, trig->QName, MQ_Q_NAME_LENGTH); strncpy(QManager, trig->QMgrName, MQ_Q_MGR_NAME_LENGTH); strncpy(odP.ObjectName, trig->UserData, MQ_PROCESS_USER_DATA_LENGTH); strncpy(queue2, trig->UserData, MQ_PROCESS_USER_DATA_LENGTH); strncpy(logfilename2, trig->EnvData, 48); }
Возможная модификация этого варианта - программа rewriter может вызываться с передачей параметров через командную строку и эту модификацию читатель может проделать самостоятельно.
Можно сделать программу mqsplitter.exe на разных языках, например, на Visual Basic 6.0 с интерфейсом, показанным на рис.9.1, и сравнить производительность программ на разных языках, реализующих один и тот же алгоритм. Такая задача будет хорошим лабораторным практикумом.
увеличить изображение
Рис. 9.1. Интерфейс программы mqsplitter на VB6
Модификацию программы mqsplitter.exe читателю предлагается сделать самостоятельно и одновременно проверить идею создания "вечного двигателя". Для создания "вечного двигателя" понадобиться изменить исходный mqsplitter.ini файл следующим образом:
| QUEUE_INPUT |
| QUEUE_OUTPUT1 |
| QUEUE_OUTPUT2 |
| C:\TEMP\ mqsplitter.log |
Программирование транзакций
Сообщения WebSphere MQ могут быть четырех типов:Наша очередная задача: на сервере 1 прочитать сообщение из входной очереди, положить её в очередь для отправки на сервер 2 как сообщение-запрос и дождаться прихода сообщения-ответа, как это показано на рис.9.2. Все это необходимо оформить в виде транзакции, для которой будет осуществляться откат в случае неполучения сообщения-ответа в течении 10 сек. Эта задача может использоваться в практических целях при нестабильной работе каналов, например выделенных. Наше приложение при откате транзакции может попытаться перенаправить сообщений из входной очереди – но это уже другая задача.
Рис. 9.2. Структура объектов WebSphere MQ
Итак, последовательность псевдокода представляется следующим образом (обратите внимание на блок 5 и опции MQMD):
Блок 1 MQCONN Блок 2 MQOPEN Блок 3 MQBEGIN Блок 4 MQGET (Input_queue) Блок 5 MQPUT (Output_queue, MQMD.MsgType = MQMT_REQUEST, MQMD.ReplyToQ = Reply_queue) Блок 6 MQGET (Reply_queue) Блок 7 If Reply time < 10 sec then MQCMIT else MQBACK; Блок 8 MQCLOSE Блок 9 MQDISC
Назовем нашу программу transmit.exe и файл инициализации transmit.ini, в котором 1-я строка – имя очереди для чтения, 2-я строка – имя очереди для записи, 3-я строка – имя очереди для ответа, 4-я строка – время ожидания ответа Reply_time = 3000мсек, как показано ниже.
QUEUE_INPUT QUEUE_OUTPUT QUEUE_REPLY 3000
Тип очереди Output_queue – remote queue и эта очередь настроена для отправки сообщений на сервер 2. На сервере 2 также выполнены соответствующие настройки и при нормальной работе каналов транзакция будет совершаться успешно. Отметим также, что сообщение-ответ формируется на сервере 2 средствами другого приложения на этом сервере. В случае остановки любого канала, которую мы произведем для отладки программы, будет происходить откат транзакции. В данной версии в начале программы производится извлечение параметров из ini-файла. Такую программу полезно также иметь в виде триггера и читателю предлагается самостоятельно модифицировать программу для считывания параметров триггера из очереди, на которую он навешивается.
Ниже приводится листинг программы transmit.cpp для Microsoft Visual C++ ver.6.0. Для каждого сообщения MsgId и the CorrelId создаются как уникальные (MSGID= MQMI_NONE и CORRELID= MQCI_NONE) и об этом подробнее в лекции 11.
Листинг 9.2. Программа transmit.cpp для Microsoft Visual C++ ver.6.0. (html, txt)
По тексту программы следует дать комментарии. Наличие опции
gmo.Options = MQGMO_SYNCPOINT;
подразумевает, что команда MQBEGIN может не указываться. Операторы
md.MsgType = MQMT_REQUEST; strncpy(md.ReplyToQ, queue_reply, MQ_Q_NAME_LENGTH);
определяют тип сообщения REQUEST и очередь ответа, заданную в QUEUE_REPLY.
На очередь QUEUE_OUTPUT (или на удаленную очередь на другом менеджере) должна быть навешена программа-триггер, который возвращает сообщения типа Reply. Если Reply-сообщение поступает в очередь QUEUE_REPLY, то транзакция завершается успешно, в противном случае производится откат транзакции и сообщение восстанавливается в очереди QUEUE_INPUT. Reply-сообщение должно иметь идентификатор CorrelId такой же, как и MsgId исходного сообщения. В данной версии программы в целях упрощения отладки не проверяется это условие и читателю предлагается самостоятельно дописать этот фрагмент кода после отладки текущей версии программы. Работа с MsgId и CorrelId будет рассмотрена подробнее в лекции 11.
Программу-триггер, которая "навешивается" на очередь QUEUE_OUTPUT (или на удаленную очередь) для формирования Reply-сообщения (md.MsgType = MQMT_REPLY;), читателю также предлагается сделать самостоятельно.
На данном примере мы познакомились с WebSphere MQ транзакциями, являющимися основой создания надежных программ для передачи сообщений. Если сообщение приходит на сервер в очередь, то программа опроса очереди открывает внешнюю транзакцию для работы с WebSphere MQ и передает управление подпрограмме записи сообщения в базу данных, которая открывает внутреннюю транзакцию для работы с базой данных (БД). Если сообщение уходит из базы данных, то открывается внешняя транзакция работы с БД, далее открывается внутренняя транзакцию для работы с WebSphere MQ и идет помещение сообщения в очередь, из которой это сообщение "улетает" на другой сервер. Завершение транзакций и откат транзакций обоих типов осуществляется взаимосвязанно. Это и есть правильный стиль интеграции приложений на основе WebSphere MQ.
O_options = MQOO_BROWSE + MQOO_INPUT_SHARED ; MQOPEN(Hcon, &odG, O_options, &Hobj, &CompCode, &Reason); if (Reason != MQRC_NONE) { printf("MQOPEN % s ended with reason code %ld\n", queue_input, Reason); } if (CompCode == MQCC_FAILED) { exit(Reason); }
O_options = MQOO_BROWSE + MQOO_INPUT_SHARED ; MQOPEN(Hcon, &odR, O_options, &Hrep, &CompCode, &Reason); if (Reason != MQRC_NONE) { printf("MQOPEN %s ended with reason code %ld\n", queue_reply, Reason); } if (CompCode == MQCC_FAILED) { exit(Reason); }
O_options = MQOO_OUTPUT ; MQOPEN(Hcon, &odP, O_options, &Hout, &CompCode, &Reason); if (Reason != MQRC_NONE) { printf("MQOPEN %s ended with reason code %ld\n", queue_output, Reason); } if (CompCode == MQCC_FAILED) { exit(Reason); }
while (CompCode == MQCC_OK) { buflen = sizeof(buffer) - 1; memcpy(md.MsgId, MQMI_NONE, sizeof(md.MsgId)); memcpy(md.CorrelId, MQCI_NONE, sizeof(md.CorrelId)); gmo.Options = MQGMO_ACCEPT_TRUNCATED_MSG + MQGMO_WAIT + MQGMO_SYNCPOINT; gmo.WaitInterval = 3000 ;
MQBEGIN (Hcon, &mbo, &CompCode, &Reason); MQGET(Hcon, Hobj, &md, &gmo, buflen, buffer, &messlen, &CompCode, &Reason); //if (Reason != MQRC_NONE) { printf("MQGET from %s ended with reason code %ld\n", queue_input, Reason); }
if ((CompCode == MQCC_OK) || (CompCode == MQCC_WARNING)) { buffer[messlen] = '\0'; /* заносим символ конец строки в буфер с прочитанным сообщением */ buflen = messlen; md.MsgType = MQMT_REQUEST; md.Report = MQRO_EXCEPTION_WITH_DATA; strncpy(md.ReplyToQ, queue_reply, MQ_Q_NAME_LENGTH); memcpy(md.Format, MQFMT_STRING, MQ_FORMAT_LENGTH);
MQPUT(Hcon, Hout, &md, &pmo, buflen, buffer, &CompCode, &Reason); if (Reason != MQRC_NONE) { printf("MQPUT to %s ended ended unsuccessfully with reason code %ld CompCode %ld\n", queue_output, Reason, CompCode ); MQBACK( Hcon, &CompCode, &Reason ) ; CompCode = MQCC_FAILED ; } else {
while (CompCode != MQCC_FAILED) { /** осуществляется проверка queue_reply **/ gmo.Options = MQGMO_ACCEPT_TRUNCATED_MSG + MQGMO_WAIT ; gmo.WaitInterval = 3000 ; memcpy(md.MsgId, MQMI_NONE, sizeof(md.MsgId)); memcpy(md.CorrelId, MQCI_NONE, sizeof(md.CorrelId)); MQGET(Hcon, Hrep, &md, &gmo, buflen, buffer, &replylen, &CompCode, &Reason); if (CompCode != MQCC_FAILED) { if (md.MsgType == MQMT_REPLY) /* report feedback */ { printf("Transaction % s=> %s successfully: %s\n", queue_input, queue_output, buffer); MQCMIT( Hcon, &CompCode, &Reason ) ; } else { printf("Transaction % s=> %s successfully, REPLY message not deliver, reason code %ld CompCode %ld\n", queue_input, queue_output, queue_reply, Reason, CompCode ); MQBACK( Hcon, &CompCode, &Reason ) ; CompCode = MQCC_FAILED ; } }
if (Reason == MQRC_NO_MSG_AVAILABLE) { printf("Transaction % s=> % s UNsuccessfully, REPLY message not deliver\n", queue_input, queue_output ); MQBACK( Hcon, &CompCode, &Reason ) ; CompCode = MQCC_FAILED ; } } } } } C_options = 0; MQCLOSE(Hcon, &Hobj, C_options, &CompCode, &Reason); if (Reason != MQRC_NONE){printf("MQCLOSE %s ended with reason code %ld\n", queue_input, Reason); } MQCLOSE(Hcon, &Hout, C_options, &CompCode, &Reason); if (Reason != MQRC_NONE){printf("MQCLOSE %s ended with reason code %ld\n", queue_output, Reason); } MQCLOSE(Hcon, &Hrep, C_options, &CompCode, &Reason); if (Reason != MQRC_NONE){printf("MQCLOSE %s ended with reason code %ld\n", queue_reply, Reason); }
MQDISC(&Hcon, &CompCode, &Reason); if (Reason != MQRC_NONE){ printf("MQDISC ended with reason code %ld\n", Reason); } return(0); }
Листинг 9.2. Программа transmit.cpp для Microsoft Visual C++ ver.6.0.
По тексту программы следует дать комментарии. Наличие опции
gmo.Options = MQGMO_SYNCPOINT;
подразумевает, что команда MQBEGIN может не указываться. Операторы
md.MsgType = MQMT_REQUEST; strncpy(md.ReplyToQ, queue_reply, MQ_Q_NAME_LENGTH);
определяют тип сообщения REQUEST и очередь ответа, заданную в QUEUE_REPLY.
На очередь QUEUE_OUTPUT (или на удаленную очередь на другом менеджере) должна быть навешена программа-триггер, который возвращает сообщения типа Reply. Если Reply-сообщение поступает в очередь QUEUE_REPLY, то транзакция завершается успешно, в противном случае производится откат транзакции и сообщение восстанавливается в очереди QUEUE_INPUT. Reply-сообщение должно иметь идентификатор CorrelId такой же, как и MsgId исходного сообщения. В данной версии программы в целях упрощения отладки не проверяется это условие и читателю предлагается самостоятельно дописать этот фрагмент кода после отладки текущей версии программы. Работа с MsgId и CorrelId будет рассмотрена подробнее в лекции 11.
Программу-триггер, которая "навешивается" на очередь QUEUE_OUTPUT ( или на удаленную очередь) для формирования Reply-сообщения (md.MsgType = MQMT_REPLY;), читателю также предлагается сделать самостоятельно.
На данном примере мы познакомились с WebSphere MQ транзакциями, являющимися основой создания надежных программ для передачи сообщений. Если сообщение приходит на сервер в очередь, то программа опроса очереди открывает внешнюю транзакцию для работы с WebSphere MQ и передает управление подпрограмме записи сообщения в базу данных, которая открывает внутреннюю транзакцию для работы с базой данных (БД). Если сообщение уходит из базы данных, то открывается внешняя транзакция работы с БД, далее открывается внутренняя транзакцию для работы с WebSphere MQ и идет помещение сообщения в очередь, из которой это сообщение "улетает" на другой сервер. Завершение транзакций и откат транзакций обоих типов осуществляется взаимосвязанно. Это и есть правильный стиль интеграции приложений на основе WebSphere MQ.
Списки распространения ( модель "один ко многим" )
Использование механизма списков распространения (Distribution List) или так называемой модели "один ко многим" требуется, например, в случае рассылки большому количеству клиентов постоянно меняющейся информации (котировки акций, курсы валют, новости и т.п.). Этот механизм позволяет одной командой MQOPEN открыть множество очередей и одной командой MQPUT положить сообщения в эти очереди. После открытия очередей возвращается один уникальный идентификатор объекта и MQPUT помещает сообщения во все эти очереди, используя этот единственный идентификатор.В версии WebSphere MQ 5.1 и выше object descriptor (MQOD) содержит поля, которые используются для списков распространения. Поле Object Descriptor RecsPresent содержит число Object Records (MQORs) и если оно больше чем 0, то это означает, что должен быть использован список распространения.
Рассмотрим этот механизм на примере задачи, когда WebSphere MQ server помещает сообщения в N очередей, как показано на рис.9.3. Эти сообщения могут дальше уходить через remote queue или их может забирать WebSphere MQ client с заданной периодичностью. Назовем нашу программу distlist.exe, файл с текстом сообщения distlist.dat и файл инициализации distlist.ini, в котором 1-я строка – имя менеджера, 2-я и последующие строки – имена очередей, как показано ниже.
QM_ ALFA Queue_ Moscow Queue_ Kiev Queue_ Alma-Ata Queue_ SPetersburg Queue_ Novosibirsk Queue_ Saratov
//last string must be blank
Рис. 9.3. Механизм Distribution List для WebSphere MQ
Ниже приводится листинг программы distlist.cpp для Microsoft Visual C++ ver.6.0.
Листинг 9.3. Программа distlist.cpp для Microsoft Visual C++ ver.6.0. (html, txt)
В завершение раздела можно сказать, что время работы механизма Distribution List для WebSphere MQ с 200, 400, 600 и т.д. очередями не зависит от производительности компьютера и не сильно зависит от количества очередей (для Notpersistent queue, persistent queue не целесообразно использовать для данной задачи ). Это наглядно видно из следующей таблицы, отражающей время работы distlist (сек) в зависимости от оперативной памяти (ОП) компьютера: 512Мбт и 1Гбт.
static void print_usage(void); static void print_responses( char * comment, PMQRR pRR, MQLONG NumQueues, PMQOR pOR);
int main(int argc, char **argv) { typedef enum {False, True} Bool; MQOD od = {MQOD_DEFAULT}; /* Object Descriptor */ MQMD md = {MQMD_DEFAULT}; /* Message Descriptor */ MQPMO pmo = {MQPMO_DEFAULT}; /* put message options */ MQHCONN Hcon; /* connection handle */ MQHOBJ Hobj; /* object handle */ MQLONG O_options; /* MQOPEN options */ MQLONG C_options; /* MQCLOSE options */ MQLONG CompCode; /* completion code */ MQLONG OpenCode; /* MQOPEN completion code */ MQLONG Reason; /* reason code */ MQCHAR48 QManager; /* queue manager name */ MQLONG buflen; /* buffer length */ char buffer[101]; /* message buffer */ MQLONG Index ; /* Index into list of queues */ MQLONG NumQueues ; /* Number of queues */ PMQRR pRR=NULL; /* Pointer to response records */ PMQOR pOR=NULL; /* Pointer to object records */ Bool DisconnectRequired=False;/* Already connected switch */ Bool Connected=False; /* Connect succeeded switch */
typedef struct { MQBYTE24 MsgId; MQBYTE24 CorrelId; } PutMsgRec, *pPutMsgRec; pPutMsgRec pPMR=NULL; /* Pointer to put msg records */ MQLONG PutMsgRecFields=MQPMRF_MSG_ID | MQPMRF_CORREL_ID;
/* Open ini file and setting value */ if ( (fptr=fopen ("distlist.ini","r" )) == NULL ) {printf("Cannot open distlist.ini file" ); print_usage(); exit(1); } else{ fgets(QManager, 48, fptr); queuenamelen = strlen(QManager) - 1; QManager[queuenamelen] = ' '; NumQueues = 0; while (queuenamelen != 0) { fgets(queue[NumQueues], 48, fptr); queuenamelen = strlen(queue[NumQueues]) - 1; queue[NumQueues][queuenamelen] = ' '; NumQueues++; } } fclose (fptr); --NumQueues; /* NumQueues - Number of Queue name */ /* Allocate response records, object records and put message records */ pRR = (PMQRR)malloc( NumQueues * sizeof(MQRR)); pOR = (PMQOR)malloc( NumQueues * sizeof(MQOR)); pPMR = (pPutMsgRec)malloc( NumQueues * sizeof(PutMsgRec));
if((NULL == pRR) || (NULL == pOR) || (NULL == pPMR)) { printf("%s(%d) malloc failed\n", __FILE__, __LINE__); exit(4); }
/* Use parameters as the name of the target queues */
for( Index = 0 ; Index < NumQueues ; Index ++) { strncpy( (pOR+Index)->ObjectName, queue[Index], (size_t)MQ_Q_NAME_LENGTH); strncpy( (pOR+Index)->ObjectQMgrName, QManager, (size_t)MQ_Q_MGR_NAME_LENGTH); }
for( Index = 0 ; Index < NumQueues ; Index ++) { MQCONN((pOR+Index)->ObjectQMgrName, &Hcon, &((pRR+Index)->CompCode), &((pRR+Index)->Reason)); if ((pRR+Index)->CompCode == MQCC_FAILED) { continue; } if ((pRR+Index)->CompCode == MQCC_OK) { DisconnectRequired = True ; } Connected = True; break ; } /* Print any non zero responses */ print_responses("MQCONN", pRR, Index, pOR);
/* Print If failed to connect to queue manager then exit. */ if( False == Connected ) { printf("Unable to connect to queue manager\n"); exit(3) ; }
if ( (fp=fopen ("distlist.dat","r" )) == NULL ) {printf("Cannot open distlist.dat file" ); exit(2); } else{ fgets(buffer, 100, fptr); buflen = (MQLONG)strlen(buffer); /* length without null */ if (buffer[buflen-1] == '\n') /* last char is a new-line */ { buffer[buflen-1] = '\0'; /* replace new-line with null */ --buflen; /* reduce buffer length */ } } fclose (fp);
tmr = time(NULL); strcpy ( buf, ctime(&tmr)); buf[strlen(buf)-5]=0; printf("Distlist start send message to list queue %s\n", buf);
/* Open the target message queue for output */ od.Version = MQOD_VERSION_2 ; od.RecsPresent = NumQueues ; od.ObjectRecPtr = pOR; od.ResponseRecPtr = pRR ; O_options = MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING;
MQOPEN(Hcon, &od, O_options, &Hobj, &OpenCode, &Reason); if (Reason == MQRC_MULTIPLE_REASONS) { print_responses("MQOPEN", pRR, NumQueues, pOR); } else { if (Reason != MQRC_NONE) { printf("MQOPEN returned CompCode=%d, Reason=%d\n", OpenCode, Reason); } }
/* Read message from the file /* Loop until null line or end of file, or there is a failure */ CompCode = OpenCode; /* use MQOPEN result for initial test */
Технологические вопросы интеграции приложений
Задачи интеграции приложений возникают достаточно часто в современных корпоративных системах. В качестве примера можно привести такую задачу. В московском динамично развивающемся банке принято решение о переходе с наиболее популярной в России банковской системы компании «Диасофт» на западную банковскую систему T24 компании TEMENOS, получившую широкое распространение в мире и в России за последние годы. Причины, побудившие к этому переходу, могут быть следующие:В этой задаче для нас интересна технология такого перехода. Совершенно очевидно, что переход от одной автоматизированной банковской системы (АБС) к другой не может пройти за один день или даже за один месяц. Этот переход будет идти несколько месяцев, а возможно, один или два года. В первую очередь это зависит от используемых технологий и системных интеграторов. Кроме этого, должен быть обучен персонал, а сам переход должен быть тщательно протестирован и осуществляться по подсистемам. Проект перехода на новую АБС составляется по подсистемам, в каждой из которых выделяются свои группы задач.
В качестве конкретной задачи рассмотрим создание интерфейса по передаче клиентов из системы «Диасофт» (АБС1) в систему T24 (АБС2). АБС1 функционирует под Windows на основе базы данных SQL Server. В АБС2 предполагается функционирование под UNIX (HP_UX) на основе базы данных ORACLE. Известна структуры данных (таблицы client) в АБС1 и АБС2. Требуется создать интерфейс: клиенты АБС1 => WebSphere MQ => клиенты АБС2. WebSphere MQ идеально подходит для решения такого класса задач по межплатформенной передаче данных, являясь мировым лидером среди транспортных систем.
Существует разные варианты решения поставленной задачи:
Первый путь ясен в технической реализации. С одной стороны при каждом обновлении таблицы client в АБС1 программа-обработчик срабатывает как триггер базы данных и помещает результаты оператора update в очередь, они приходят на АБС2, где своя программа-обработчик срабатывает как триггер очереди и помещает сообщение в таблицу client АБС2. WebSphere MQ гарантирует доставку сообщений. Разработчикам приложений (программ-обработчиков) остается позаботиться 1) о преобразовании форматов АБС1 в АБС2 в одной из программ-обработчиков, например, на платформе Windows; 2) о надежности такой передачи с учетом механизмов транзакционности в WebSphere MQ и в базах данных одновременно. Ведь в банковских системах ничего не должно и не может пропасть! Укрупненная блок-схема программы-обработчика в АБС2 для такого надежного транзакционного взаимодействия выглядит следующим образом.
Блок 1 MQCONN; MQOPEN; Блок 2 MQBEGIN; MQGET; Блок 3 Begin Tran Блок 4 UPDATE CLIENT SET ... WHERE ... Блок 5 If Error = 0 then Commit Tran else Rollback Tran; Блок 6 If Error = 0 then MQCMIT else MQBACK; Блок 7 MQCLOSE; MQDISC;
В этой программе транзакция WebSphere MQ является внешней по отношению к транзакции базы данных. В программе-обработчике для АБС1 наоборот транзакция WebSphere MQ будет внутренней по отношению к транзакции базы данных. Таким образом, реализация интерфейса по первому варианту не вызывает технических проблем и в следующем разделе мы рассмотрим пример на программирование транзакций для WebSphere MQ. Остается отметить один важный момент. Первый вариант не перспективен при создании нескольких десятков интерфейсов и более. Во-первых, затраты на разработку возрастут по сравнению со вторым и третьим вариантами, когда используются специализированные средства. Во-вторых, сопровождение нескольких десятков разных программ, написанных разными программистами, становиться весьма серьезной задачей, а их модификация после увольнения авторов программ или прекращения с ними договорных отношений может оказаться неразрешимой проблемой. К сожалению, жизнь такова, что программисты увольняются, программы интерфейсов живут по несколько лет и их требуется модифицировать. Поэтому нужно очень серьезно подумать в самом начале интеграционного проекта, какой выбрать путь для реализации интерфейсов. Если будет создано несколько интерфейсов по варианту 1, то переделывать их по варианту 2 – задача малоприятная и неблагодарная.
Тем не менее, при небольшом числе интерфейсов рекомендуется вариант 1, как наиболее экономический, к рассмотрению которого мы и переходим. WebSphere BI Broker будет рассмотрен в лекции 12. К сожалению, рассмотрение средств интеграции с WebSphere MQ в системе T24 (вариант 3) выходит за пределы данного курса лекций.
Интеграция приложений на основе WebSphere MQ
MQLONG CompCode; MQLONG Reason; MQOD
|
/*************************************************************************************/ /* Имя программы: AMQSGAMA */ /* Описание: Основанная на модели Publish/Subscribe программа */ /* моделирует результаты футбольного матча и */ /* отправляет их от издателя к брокеру */ /* Statement: Licensed Materials - Property of IBM */ /* SupportPac MA0E */ /* (C) Copyright IBM Corp. 1999 */ /*************************************************************************************/ #include static const MQRFH DefaultMQRFH = {MQRFH_DEFAULT}; typedef struct { MQCHAR32 Team1; MQCHAR32 Team2; } Match_Teams, *pMatch_Teams; void BuildMQRFHeader( PMQBYTE pStart , PMQLONG pDataLength , MQCHAR TopicType[] ); void PutPublication( MQHCONN hConn , MQHOBJ hObj , PMQBYTE pMessage , MQLONG messageLength , PMQLONG pCompCode , PMQLONG pReason ); int main(int argc, char **argv) { MQHCONN hConn = MQHC_UNUSABLE_HCONN; MQHOBJ hObj = MQHO_UNUSABLE_HOBJ; MQLONG CompCode; MQLONG Reason; MQOD od = { MQOD_DEFAULT }; MQLONG Options; PMQBYTE pMessageBlock = NULL; MQLONG messageLength; MQLONG timeRemaining; MQLONG delay; PMQCHAR pScoringTeam; pMatch_Teams pTeams; MQCHAR32 team1; MQCHAR32 team2; char QMName[MQ_Q_MGR_NAME_LENGTH+1] = ""; MQLONG randomNumber; MQLONG ConnReason; /* Проверка аргументов программы */ if( (argc < 3)||(argc > 4)||(strlen(argv[1]) > 31)||(strlen(argv[2]) > 31) ) { printf("Usage: amqsgam team1 team2 if( CompCode == MQCC_OK ) { srand( (unsigned)(time( NULL )) + (unsigned)(team1[0] + team2[(strlen(team2) - 1)]) ); timeRemaining = MATCH_LENGTH; messageLength = DEFAULT_MESSAGE_SIZE; pMessageBlock = (PMQBYTE)malloc(messageLength); if( pMessageBlock == NULL ) { printf("Unable to allocate storage\n"); } else { if( CompCode == MQCC_OK ) { /* создание MQRFH для публикации о начале матча */ BuildMQRFHeader( pMessageBlock, &messageLength, MATCH_STARTED ); pTeams = (pMatch_Teams)(pMessageBlock + messageLength); strcpy(pTeams->Team1, team1); strcpy(pTeams->Team2, team2); messageLength += sizeof(Match_Teams); printf("Match between %s and %s\n", team1, team2); /* помещение сообщения (публикации) в очередь потока */ PutPublication( hConn, hObj, pMessageBlock, messageLength, &CompCode, &Reason ); if( CompCode != MQCC_OK ) { printf("MQPUT failed with CompCode %d and Reason %d\n", CompCode, Reason); } else { /* Моделирование попытки забить один из 5 голов (каждые 30 сек) */ while( (timeRemaining > 0)&&(CompCode == MQCC_OK) ) { randomNumber = rand(); delay = REAL_TIME_RATIO + ( (randomNumber * MATCH_LENGTH) / (RAND_MAX * AVERAGE_NUM_OF_GOALS)); if( delay > timeRemaining ) delay = timeRemaining; msSleep(delay); timeRemaining -= delay; if( timeRemaining > 0 ) { if( (randomNumber % 2) == 0 ) /* Шанс забить гол - 50 процентов */ { messageLength = DEFAULT_MESSAGE_SIZE; BuildMQRFHeader( pMessageBlock , &messageLength, SCORE_UPDATE ); printf("GOAL! "); pScoringTeam = (PMQCHAR)pMessageBlock + messageLength; if( rand() < (RAND_MAX/2) ) { strcpy(pScoringTeam, team1); printf(team1); } else { strcpy(pScoringTeam, team2); printf(team2); } printf(" scores after %d minutes\n", ((MATCH_LENGTH - timeRemaining)/REAL_TIME_RATIO)); messageLength += sizeof(MQCHAR32); /* помещение сообщения о забитом голе в очередь потока */ PutPublication( hConn, hObj, pMessageBlock, messageLength, &CompCode, &Reason ); if( CompCode != MQCC_OK ) printf("MQPUT failed with CompCode %d and Reason %d\n", CompCode, Reason); } } } /* конец цикла по времени окончания матча ( timeRemaining ) */ if( CompCode == MQCC_OK ) { printf("Full time\n"); messageLength = DEFAULT_MESSAGE_SIZE; BuildMQRFHeader( pMessageBlock , &messageLength , MATCH_ENDED ); pTeams = (pMatch_Teams)(pMessageBlock + messageLength); strcpy(pTeams->Team1, team1); strcpy(pTeams->Team2, team2); messageLength += sizeof(Match_Teams); /* помещение сообщения о конце матча в очередь потока */ PutPublication( hConn, hObj, pMessageBlock, messageLength, &CompCode, &Reason ); if( CompCode != MQCC_OK ) printf("MQPUT failed with CompCode %d and Reason %d\n", CompCode, Reason); } } } free( pMessageBlock ); } /* end of else (pMessageBlock != NULL) */ } if( hObj != MQHO_UNUSABLE_HOBJ ) { MQCLOSE( hConn , &hObj, MQCO_NONE, &CompCode , &Reason ); if( CompCode != MQCC_OK ) printf("MQCLOSE failed with CompCode %d and Reason %d\n", CompCode, Reason); } if( (hConn != MQHC_UNUSABLE_HCONN) &&(ConnReason != MQRC_ALREADY_CONNECTED) ) { MQDISC( &hConn, &CompCode, &Reason ); if( CompCode != MQCC_OK ) printf("MQDISC failed with CompCode %d and Reason %d\n", CompCode, Reason); } return(0); } /* end of main Function */ /* Function Name : BuildMQRFHeader */ void BuildMQRFHeader( PMQBYTE pStart, PMQLONG pDataLength, MQCHAR TopicType[] ) { PMQRFH pRFHeader = (PMQRFH)pStart; PMQCHAR pNameValueString; memset((PMQBYTE)pStart, 0, *pDataLength); memcpy( pRFHeader, &DefaultMQRFH, (size_t)MQRFH_STRUC_LENGTH_FIXED); memcpy( pRFHeader->Format, MQFMT_STRING, (size_t)MQ_FORMAT_LENGTH); pRFHeader->CodedCharSetId = MQCCSI_INHERIT; pNameValueString = (MQCHAR *)pRFHeader + MQRFH_STRUC_LENGTH_FIXED; strcpy(pNameValueString, MQPS_COMMAND_B); strcat(pNameValueString, MQPS_PUBLISH); strcat(pNameValueString, MQPS_PUBLICATION_OPTIONS_B); strcat(pNameValueString, MQPS_NO_REGISTRATION); strcat(pNameValueString, MQPS_TOPIC_B); strcat(pNameValueString, TOPIC_PREFIX); strcat(pNameValueString, TopicType); *pDataLength = MQRFH_STRUC_LENGTH_FIXED + ((strlen(pNameValueString)+15)/16)*16; pRFHeader->StrucLength = *pDataLength; } /* Function Name : PutPublication */ void PutPublication( MQHCONN hConn, MQHOBJ hObj, PMQBYTE pMessage, MQLONG messageLength, PMQLONG pCompCode, PMQLONG pReason ) { MQPMO pmo = { MQPMO_DEFAULT }; MQMD md = { MQMD_DEFAULT }; memcpy(md.Format, MQFMT_RF_HEADER, (size_t)MQ_FORMAT_LENGTH); md.MsgType = MQMT_DATAGRAM; md.Persistence = MQPER_PERSISTENT; pmo.Options |= MQPMO_NEW_MSG_ID; MQPUT( hConn, hObj, &md, &pmo, messageLength, pMessage, pCompCode, pReason ); } |
| Листинг 10.1. Программа amqsgama |
| Закрыть окно |
MQCHAR32 team1;
MQCHAR32 team2;
char QMName[MQ_Q_MGR_NAME_LENGTH+1] = "";
MQLONG randomNumber;
MQLONG ConnReason;
/* Проверка аргументов программы */
if( (argc < 3)||(argc > 4)||(strlen(argv[1]) > 31)||(strlen(argv[2]) > 31) )
{
printf("Usage: amqsgam team1 team2 \n");
printf(" Maximum 31 characters per team name,\n");
printf(" no spaces or '\"' characters allowed.\n");
exit(0);
}
else
{
strcpy(team1, argv[1]);
strcpy(team2, argv[2]);
}
/* Использовать default queue manager или заданный в зависимости от наличия аргумена */
if (argc > 3) strcpy(QMName, argv[3]);
MQCONN( QMName, &hConn, &CompCode, &ConnReason );
if( CompCode == MQCC_FAILED )
{
printf("MQCONN failed with CompCode %d and Reason %d\n", CompCode, ConnReason);
}
else if( ConnReason == MQRC_ALREADY_CONNECTED )
{
CompCode = MQCC_OK;
}
if( CompCode == MQCC_OK )
{
strncpy(od.ObjectName, STREAM, (size_t)MQ_Q_NAME_LENGTH);
Options = MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING;
MQOPEN( hConn, &od, Options, &hObj, &CompCode, &Reason );
if( CompCode != MQCC_OK )
{
printf("MQOPEN failed to open \"%s\"\nwith CompCode %d and Reason %d\n",
od.ObjectName, CompCode, Reason);
}
}
if( CompCode == MQCC_OK )
{
srand( (unsigned)(time( NULL ))
+ (unsigned)(team1[0] + team2[(strlen(team2) - 1)]) );
timeRemaining = MATCH_LENGTH;
messageLength = DEFAULT_MESSAGE_SIZE;
pMessageBlock = (PMQBYTE)malloc(messageLength);
if( pMessageBlock == NULL )
{
printf("Unable to allocate storage\n");
}
else
{
if( CompCode == MQCC_OK )
{
/* создание MQRFH для публикации о начале матча */
BuildMQRFHeader( pMessageBlock, &messageLength, MATCH_STARTED );
pTeams = (pMatch_Teams)(pMessageBlock + messageLength);
strcpy(pTeams->Team1, team1);
strcpy(pTeams->Team2, team2);
messageLength += sizeof(Match_Teams);
printf("Match between %s and %s\n", team1, team2);
/* помещение сообщения (публикации) в очередь потока */
PutPublication( hConn, hObj, pMessageBlock, messageLength, &CompCode, &Reason );
if( CompCode != MQCC_OK )
{
printf("MQPUT failed with CompCode %d and Reason %d\n", CompCode, Reason);
}
else
{
/* Моделирование попытки забить один из 5 голов (каждые 30 сек) */
while( (timeRemaining > 0)&&(CompCode == MQCC_OK) )
{
randomNumber = rand();
delay = REAL_TIME_RATIO
+ ( (randomNumber * MATCH_LENGTH)
/ (RAND_MAX * AVERAGE_NUM_OF_GOALS));
if( delay > timeRemaining ) delay = timeRemaining;
msSleep(delay);
timeRemaining -= delay;
if( timeRemaining > 0 )
{
if( (randomNumber % 2) == 0 ) /* Шанс забить гол - 50 процентов */
{
messageLength = DEFAULT_MESSAGE_SIZE;
BuildMQRFHeader( pMessageBlock , &messageLength, SCORE_UPDATE );
printf("GOAL! ");
pScoringTeam = (PMQCHAR)pMessageBlock + messageLength;
if( rand() < (RAND_MAX/2) )
{
strcpy(pScoringTeam, team1);
printf(team1);
}
else
{
strcpy(pScoringTeam, team2);
printf(team2);
}
printf(" scores after %d minutes\n", ((MATCH_LENGTH - timeRemaining)/REAL_TIME_RATIO));
messageLength += sizeof(MQCHAR32);
/* помещение сообщения о забитом голе в очередь потока */
PutPublication( hConn, hObj, pMessageBlock, messageLength, &CompCode, &Reason );
if( CompCode != MQCC_OK )
printf("MQPUT failed with CompCode %d and Reason %d\n", CompCode, Reason);
}
}
} /* конец цикла по времени окончания матча ( timeRemaining ) */
if( CompCode == MQCC_OK )
{
printf("Full time\n");
messageLength = DEFAULT_MESSAGE_SIZE;
BuildMQRFHeader( pMessageBlock , &messageLength , MATCH_ENDED );
pTeams = (pMatch_Teams)(pMessageBlock + messageLength);
strcpy(pTeams->Team1, team1);
strcpy(pTeams->Team2, team2);
messageLength += sizeof(Match_Teams);
/* помещение сообщения о конце матча в очередь потока */
PutPublication( hConn, hObj, pMessageBlock, messageLength, &CompCode, &Reason );
if( CompCode != MQCC_OK )
printf("MQPUT failed with CompCode %d and Reason %d\n", CompCode, Reason);
}
}
}
free( pMessageBlock );
} /* end of else (pMessageBlock != NULL) */
}
if( hObj != MQHO_UNUSABLE_HOBJ )
{
MQCLOSE( hConn , &hObj, MQCO_NONE, &CompCode , &Reason );
if( CompCode != MQCC_OK )
printf("MQCLOSE failed with CompCode %d and Reason %d\n", CompCode, Reason);
}
if( (hConn != MQHC_UNUSABLE_HCONN) &&(ConnReason != MQRC_ALREADY_CONNECTED) )
{
MQDISC( &hConn, &CompCode, &Reason );
if( CompCode != MQCC_OK )
printf("MQDISC failed with CompCode %d and Reason %d\n", CompCode, Reason);
}
return(0);
}
/* end of main Function */
/* Function Name : BuildMQRFHeader */
void BuildMQRFHeader( PMQBYTE pStart, PMQLONG pDataLength, MQCHAR TopicType[] )
{
PMQRFH pRFHeader = (PMQRFH)pStart;
PMQCHAR pNameValueString;
memset((PMQBYTE)pStart, 0, *pDataLength);
memcpy( pRFHeader, &DefaultMQRFH, (size_t)MQRFH_STRUC_LENGTH_FIXED);
memcpy( pRFHeader->Format, MQFMT_STRING, (size_t)MQ_FORMAT_LENGTH);
pRFHeader->CodedCharSetId = MQCCSI_INHERIT;
pNameValueString = (MQCHAR *)pRFHeader + MQRFH_STRUC_LENGTH_FIXED;
strcpy(pNameValueString, MQPS_COMMAND_B);
strcat(pNameValueString, MQPS_PUBLISH);
strcat(pNameValueString, MQPS_PUBLICATION_OPTIONS_B);
strcat(pNameValueString, MQPS_NO_REGISTRATION);
strcat(pNameValueString, MQPS_TOPIC_B);
strcat(pNameValueString, TOPIC_PREFIX);
strcat(pNameValueString, TopicType);
*pDataLength = MQRFH_STRUC_LENGTH_FIXED + ((strlen(pNameValueString)+15)/16)*16;
pRFHeader->StrucLength = *pDataLength;
}
/* Function Name : PutPublication */
void PutPublication( MQHCONN hConn, MQHOBJ hObj, PMQBYTE pMessage,
MQLONG messageLength, PMQLONG pCompCode, PMQLONG pReason )
{
MQPMO pmo = { MQPMO_DEFAULT };
MQMD md = { MQMD_DEFAULT };
memcpy(md.Format, MQFMT_RF_HEADER, (size_t)MQ_FORMAT_LENGTH);
md.MsgType = MQMT_DATAGRAM;
md.Persistence = MQPER_PERSISTENT;
pmo.Options |= MQPMO_NEW_MSG_ID;
MQPUT( hConn, hObj, &md, &pmo, messageLength, pMessage, pCompCode, pReason );
}
Общие сведения о модели публикация-подписка
Механизм публикация-подписка (Publish/Subscribe) позволяет поставлять информацию от поставщика к потребителю. Эта модель стала особенно популярной в последние годы благодаря тому, что часто меняющаяся информация может поставляться постоянно многим получателям. Одним из типичных примеров такой информации являются данные на рынке акций и валют. В такой модели издателю необязатеьно знать о местонахождении получателя и наоборот. В модели Request/Reply движение информации начинается по запросу потребителя (клиента). В модели Publish/Subscribe движение информации начинается по мере ее появления и поступления от поставщика.Поставщика информации принято называть издатель (publisher). издатель предлагает информацию на определенные темы. Потребитель информации называется подписчиком (subscriber), он подписывается на получение информации на определенные темы. Информация, которую получает один подписчик, может передаваться другим подписчикам.
Информация, посылаемая как сообщение, характеризуется темой. издатель посылает информацию только на те темы, на которые сделана подписка. Взаимодействие между издателями и подписчиками контролируется посредником или брокером (broker). Взаимосвязанные темы группируются совместно в потоки (stream). издатель может применять потоки для ограничения диапазонов тем издателей и подписчиков. Через брокера идет поток, который использует все темы. На рис.10.1 представлена схема, иллюстрирующая взаимодействие брокеров, издателей и подписчиков.
Рис. 10.1. Схема взаимодействия брокеров, издателей и подписчиков
Общий подход работы механизма Publish/Subscribe лучше всего иллюстрируется на примере трех видов сценариев, которые реализуются на основе командных сообщений.
Сценарий издатель-брокер.
Сценарий подписчик-брокеру.
Сценарий брокер-брокер реализуется в виде следующих взаимодействий
Механизм Publish/Subscribe поддерживает брокеров на основе функций WebSphere MQ на платформах для AIX, HP-UX, Linux, Windows NT, Microsoft Windows 2000 и Sun Solaris. Допустимо иметь по одному брокеру на менеджере очередей. брокер имеет то же самое имя, что и менеджер. Приложения могут писаться на основе стандартных приемов программирования с использованием технологий Message Queue Interface (MQI) или Application Messaging Interface (AMI). Издатели и подписчики могут быть на любых платформах, на которых поддерживается WebSphere MQ, например, издатель - на OS/390 и подписчик - на OS/2. брокеры могут объединяться в сеть, в которой есть корневой брокер, брокеры-родители и брокеры-дети.
Для работы с механизмом Publish/Subscribe существует несколько основных функций или, иначе называемых, командных сообщений, в которых помещается команда брокеру. Синтаксис этих функций имеет простые правила при определении темы. Тема задается строкой длиной не более 256 байт без пробелов и двойных кавычек ("). Тема и подтемы разделяются символом "/" (без пробелов), например, для рынка акций формат темы задается следующим образом:
Регион/СекторРынка/Компания
Конкретные темы выглядят следующим образом:
NewYork/InformationTechnology/IBM
Этот синтаксис разрешает в строках иметь символы:
* - означающий ноль или любое количество произвольных символов; ? – означающий один произвольный символ.
Данный синтаксис позволит в дальнейшем определить, например, такие темы для подписки на рынке акций как:
* получение всех цен на акции со всех рынков мира; London/* получение всех цен на акции с Лондонской биржи; NewYork/Banks/* получение цен акций всех нью-йоркских банков; */*/IBM получение всех цен на акции компании ИБМ на всех рынках мира.
Символ % позволяет использовать специальные символы * и ? в строках, например, 'ABC%*D' означает 'ABC*D'.
В числе основных функций для работы с механизмом Publish/Subscribe (MQPSCommand) следует назвать:
| RegPub | Регистрация издателя (Register Publisher) |
| RegSub | Регистрация подписчика (Register Subscriber) |
| Publish | Публикация |
| ReqUpdate | Запрос от издателя к брокеру на обновление публикации на заданную тему (Request Update) |
| DeletePub | Удаление публикации (Delete Publication) |
| DeregPub | Отказ от регистрации издателя (Deregister Publisher) |
| DeregSub | Отказ от регистрации подписчика (Deregister Subscriber) |
Для осуществления работы издателя и подписчика используется формат MQRFH (Rules and Formatting Header - RF Header) WebSphere MQ сообщения. формат MQRFH представляет собой структуру заголовка переменной длины, в которую приложение размещает данные в виде префикса при публикации. В эту структуру входят следующие переменные:
typedef struct tagMQRFH { MQCHAR4 StrucId; /* Идентификатор структуры */ MQLONG Version; /* Номер версии структуры */ MQLONG StrucLength; /* Общая длина MQRFH */ MQLONG Encoding; /* Data encoding */ MQLONG CodedCharSetId; /* Идентификатор множества перекодировки */ MQCHAR8 Format; /* Имя формата */ MQLONG Flags; /* Флаги */ } MQRFH;
Этот заголовок также включает строку NameValueString, в которой приложение публикации или подписки помещает команды, которые должен выполнить брокер. Поле StrucLength в заголовке определяет длину структуры заголовка, включительно с переменной длины NameValueString в конце структуры. Поля Encoding, CodedCharSetId и Format описывают структуру данных в заголовке публикации.
Примеры работы механизмов публикация-подписка
Теперь после знакомства с технологией публикация-подписка следует рассмотреть работу модели Publish/Subscribe на простых примерах. Для этого понадобиться инсталлировать SupportPacs MA0C: WebSphere MQ (WebSphere MQ) Publish/Subscribe с сайта ИБМ:http://www-306.ibm.com/software/integration/support/supportpacs/category.htmlПосле этого можно стартовать брокер на менеджере очередей командой:
strmqbrk -m QMgrName
Для отображения состояния брокера можно использовать команду dspmqbrk:
dspmqbrk -m QMgrName
В ответ появиться следующее сообщение:
WebSphere MQ message broker for queue manager QMgrName running
Теперь брокер готов получать команды от издателей и подписчиков.
На каждом менеджере может быть стартован только один брокер.
В менеджере есть необходимые системные очереди, которые можно увидеть командой
runmqsc QMgrName display qlocal(SYSTEM.BROKER.*) end
Следует сразу отметить, что завершение работы брокера осуществляется командой endmqbrk перед окончанием работы менеджера: endmqbrk -m QMgrName.
Работу издателя можно продемонстрировать с помощью программы amqsgama, предложенной в SupportPacs MA0C в качестве теста. Эта программа издателя из перечня спортивных тем для подписки (табл.10.1) помещает на брокер сообщения о футбольных матчах (Sport/Soccer/Event/ - в таблице данная тема выделена курсивом) и проверяет ответы брокера.
спорт/футбол/* спорт/теннис/* спорт/баскетбол/* | спорт/футбол/расписание игр спорт/футбол/события спорт/футбол/обзоры |
Формат запуска программы:
amqsgama TeamName1 TeamName2 QMgrName
Результаты работы программы, моделирующей случайным образом забивание голов той или иной командой, выглядит следующим образом (рис. 10.3):
Рис. 10.3. Результаты работы программы издателя
Для работы программы необходимо создание очереди: SAMPLE.BROKER.RESULTS.STREAM.
Именно в эту очередь поступают сообщения от издателя. Необходимо также, чтобы был запущен брокер. Программа подписчика должна стартовать раньше, чем программа издателя amqsgama, чтобы отобразить результаты игры полностью. Все используемые функции в программе служат для подключения к менеджеру брокера и публикации событий о начале матча, окончании матча и забивание гола.
Блочная структура программы выглядит следующим образом.
Подключение к менеджеру брокера (MQCONN) Открытие очереди потока брокера (MQOPEN) Инициализация таймера матча Генерация MQRFH для публикации события о начале матча Добавление имен команд в данные Помещение публикации в очередь потоков Начало цикла по времени матча: засыпание на случайный период попытка забить гол (50% вероятность) генерация публикации о забитом голе (RFH для ScoreUpdate) случайный выбор команды, забившей гол добавление имени команды в данные для публикации помещение публикации в очередь потоков Окончание цикла по времени матча Генерация MQRFH для публикации события о конце матча Добавление имен команд для публикации Помещение публикации в очередь потоков Закрытие очереди потока брокера (MQCLOSE) Отключение от менеджера брокера (MQDISC)
Программа amqsgama имеет следующий код:
Листинг 10.1. Программа amqsgama (html, txt)
В качестве комментария следует отметить, что функция BuildMQRFHeader формирует значения по умолчанию для заголовка MQRFH, устанавливает параметры format и CCSID пользовательских данных. В строку NameValueString добавляются команды, тема и опции для публикации и она выравнивается на 16-ти байтовую границу. StrucLength в MQRFH устанавливается как общая длина. Входными параметрами функции являются pStart – начало блока сообщения, TopicType[] – строка с именем темы. Входным и выходным параметром одновременно является pDataLength – размер блока сообщения при входе и размер выходного блока информации.
Функция PutPublication формирует сообщение для вывода в очередь брокера с помощью команды MQPUT. Входными параметрами функции являются hConn – идентификатор менеджера для команды MQHCONN, hObj – идентификатор очереди, pMessage – идентификатор на начало блока сообщения, messageLength – длина данных в сообщении. Выходными параметрами функции являются pCompCode и pReason – коды завершения команды MQPUT.
Работу подписчика можно продемонстрировать с помощью программы amqsresa из состава SupportPacs MA0C, которая подписывается у брокера на заданную тему (футбол) и получает сообщения от брокера. Формат запуска программы:
amqsresa QMgrName
где QmgrName – имя менеджера очередей, на котором запущен брокер.
Необходимая тема подписки (TOPIC = "Sport/Soccer/*") и очереди для подписчика заданы в теле программы (эти параметры рекомендуется выносить в командную строку или файл инициализации для создания универсальных программ – примеч. автора).
Для работы программы необходимо создание очередей:
runmqsc QMgrName define qlocal(SAMPLE.BROKER.RESULTS.STREAM) define qlocal(RESULTS.SERVICE.SAMPLE.QUEUE) define qlocal(SYSTEM.BROKER.CONTROL.QUEUE) end
Результаты работы программы amqsresa, получающей сообщения от брокера, выглядят следующим образом (рис. 10.4):
Рис. 10.4. Результаты работы программы подписчика
Объем программы подписчика amqsresa более 2000 строк (в том числе комментариев – 40%) и это не позволяет привести ее в данной лекции. Стоит ограничиться лишь кратким алгоритмом.
Подключение к менеджеру брокера (MQCONN ) Открытие очереди потока брокера и подписчика (MQOPEN ) Генерация MQRFH и подписка на все события Ожидание появления сообщений в очереди подписчика (до 3 минут) Извлечение из очереди MQGET всех публикаций Отбор публикации по теме "Sport/Soccer/*” Обработка и отображение результатов публикации в зависимости от событий (начало матча, конец матча, изменение счета) Выход из цикла по концу матча или по таймеру Закрытие очереди потока брокера и подписчика (MQCLOSE) Отключение от менеджера брокера (MQDISC)
В комментарии к алгоритму следует отметить, что подписка на все события (в алгоритме выделено курсивом) вряд ли объяснима, скорее это сделано в учебных целях. подписчику нет необходимости получать все публикации, поэтому в команде регистрации подписчика (RegSub) целесообразно осуществлять подписку сразу на заданную тему.
В заключение лекции можно привести график времени доставки публикации (мсек) в зависимости от количества подписчиков (рис.10.5), полученный на компьютере RISC/6000, 200MHz, 1 GB RAM с операционной системой AIX 4.3.0 [20]. Этот график показывает, что механизм Publish/Subscribe обеспечивает более высокую производительность, чем приложения, созданные на основе классического подхода с помощью MQI интерфейса и Distribution List.
Рис. 10.5. Зависимость времени доставки публикации от количества подписчиков
Блочная структура программы выглядит следующим образом.
Подключение к менеджеру брокера (MQCONN) Открытие очереди потока брокера (MQOPEN) Инициализация таймера матча Генерация MQRFH для публикации события о начале матча Добавление имен команд в данные Помещение публикации в очередь потоков Начало цикла по времени матча: засыпание на случайный период попытка забить гол (50% вероятность) генерация публикации о забитом голе (RFH для ScoreUpdate) случайный выбор команды, забившей гол добавление имени команды в данные для публикации помещение публикации в очередь потоков Окончание цикла по времени матча Генерация MQRFH для публикации события о конце матча Добавление имен команд для публикации Помещение публикации в очередь потоков Закрытие очереди потока брокера (MQCLOSE) Отключение от менеджера брокера (MQDISC)
Программа amqsgama имеет следующий код:
/*************************************************************************************/ /* Имя программы: AMQSGAMA */ /* Описание: Основанная на модели Publish/Subscribe программа */ /* моделирует результаты футбольного матча и */ /* отправляет их от издателя к брокеру */ /* Statement: Licensed Materials - Property of IBM */ /* SupportPac MA0E */ /* (C) Copyright IBM Corp. 1999 */ /*************************************************************************************/ #include
static const MQRFH DefaultMQRFH = {MQRFH_DEFAULT}; typedef struct { MQCHAR32 Team1; MQCHAR32 Team2; } Match_Teams, *pMatch_Teams; void BuildMQRFHeader( PMQBYTE pStart , PMQLONG pDataLength , MQCHAR TopicType[] ); void PutPublication( MQHCONN hConn , MQHOBJ hObj , PMQBYTE pMessage , MQLONG messageLength , PMQLONG pCompCode , PMQLONG pReason );
int main(int argc, char **argv) { MQHCONN hConn = MQHC_UNUSABLE_HCONN; MQHOBJ hObj = MQHO_UNUSABLE_HOBJ; MQLONG CompCode; MQLONG Reason; MQOD od = { MQOD_DEFAULT }; MQLONG Options; PMQBYTE pMessageBlock = NULL; MQLONG messageLength; MQLONG timeRemaining; MQLONG delay; PMQCHAR pScoringTeam; pMatch_Teams pTeams; MQCHAR32 team1; MQCHAR32 team2; char QMName[MQ_Q_MGR_NAME_LENGTH+1] = ""; MQLONG randomNumber; MQLONG ConnReason;
/* Проверка аргументов программы */ if( (argc < 3)||(argc > 4)||(strlen(argv[1]) > 31)||(strlen(argv[2]) > 31) ) { printf("Usage: amqsgam team1 team2
if( CompCode == MQCC_OK ) { srand( (unsigned)(time( NULL )) + (unsigned)(team1[0] + team2[(strlen(team2) - 1)]) ); timeRemaining = MATCH_LENGTH; messageLength = DEFAULT_MESSAGE_SIZE; pMessageBlock = (PMQBYTE)malloc(messageLength); if( pMessageBlock == NULL ) { printf("Unable to allocate storage\n"); } else { if( CompCode == MQCC_OK ) {
Технология разработки приложений для модели публикация-подписка
Задача создания собственных приложений Издателя и подписчика рассматривается на следующей упрощенной модели: один издатель, один брокер и один подписчик (рис.10.2). Будет использоваться формат сообщений WebSphere MQ – MQRFH и классический MQI интерфейс. Для создания приложений необходимо иметь руководство по командам и опциям Publish/Subscribe, а также некоторые знания по программированию на С.
Рис. 10.2. Модель Издатель/Подписчик
Приложение Издателя должно публиковать символьные строки, задаваемые пользователем на определенные темы. Следовательно, такая программа с именем publisher может иметь следующий формат запуска:
publisher Topic Command QMgrName PubQueue
где Topic – тема публикации, символьная строка длиной не более 256 байт; Command – команды Издателя для брокера (RegPub, Publish, ReqUpdate, DeletePub, DeregPub), PubQueue - очередь издателя. Текст публикации вводится в командном окне с запущенной программой.
Приложение подписчика должно иметь возможность зарегистрироваться (подписаться) на заданные темы и отображать результаты полученных публикаций. Программа подписчика с именем subscriber может иметь формат запуска:
subscriber Topic QMgrName SubQueue
где Topic – тема подписки, SubQueue - очередь подписчика. Текст публикации на тему Topic отображается в командном окне с запущенной программой subscriber.
Для работы приложений требуется создание очередей: одна у Издателя и одна у подписчика, наименования которых, соответственно, Publisher_queue и Subscriber_queue. издатель будет получать сообщения от брокера через Publisher_queue. подписчик - регистрировать темы и получать публикации через Subscriber_queue. Создание этих очередей осуществляется простой командой runmqsc:
runmqsc QMgrName define qlocal(имя очереди) end
Следует рассмотреть потоки сообщений и то, как сообщения по определенной теме находят своего подписчика.
SYSTEM.BROKER.DEFAULT.STREAM
Сообщения публикация-подписка имеет время жизни, по истечению которого они удаляются. Сообщения публикация-подписка являются постоянными сообщениями (persistent) и восстанавливаются после перезагрузки менеджера и/или брокера.
Также как и сообщения WebSphere MQ потоки информации от издателя к подписчику являются асинхронными. Если брокер не работает, то публикация будет оставаться в потоковой очереди до тех пор, пока брокер не стартует. Если приложение подписчика не активно, то публикация будет оставаться в очереди подписчика.
Основные шаги, из которых складывается создание Приложения издателя. Таких шагов для программы publisher будет 7.
Шаг 1. Для того чтобы положить сообщение в очередь потоков брокера, необходимо подключиться к менеджеру брокера и открыть очередь командой MQOPEN для помещения сообщений.
Шаг 2. Для публикации необходимо сформировать MQRFH структуру (см. руководство по WebSphere MQ Publish/Subscribe). Все поля этой структуры должны иметь определенные значения. Некоторые значения MQRFH должны быть изменены по сравнению со значениями по умолчанию перед публикацией или в тот момент, когда мы определим значения этих полей.
Шаг 3. Сразу за структурой MQRFH должна следовать символьная строка NameValueString. Указатель pNameValueString определяет начальную позицию NameValueString в теле сообщения.
Шаг 4. Содержимое строки NameValueString должно включать всю необходимую информацию о публикации и всю необходимую последовательность команд для формирования непрерывной символьной строки нашей публикации. Содержимое строки NameValueString позволяет брокеру определить Publish/Subscribe команды и порядок их обработки.
Шаг 5. Поле StrucLength должно содержать длину MQRFH структуры и сопровождающей его строки NameValueString. Длина MQRFH фиксирована и длина NameValueString – переменная. Значение StrucLength позволяет не применять разделитель конца строки в NameValueString, хотя и он может быть использован, если это необходимо приложению-подписчику. MQRFH и NameValueString выравниваются на границе 16 байт автоматически.
Шаг 6. Данные о публикации ( в данном случае строка данных для публикации) помещаются сразу после MQFRH и NameValueString структуры, указатель pUserData должен быть установлен на начальную позицию строки введенных данных о публикации.
Шаг 7. Осуществляется процедура тестирования работы программы. Программа компилируется, устраняются ошибки компиляции. Она вызывается, например, командой:
publisher TestTopic Publish QM_broker Publisher_queue
В командном окне программы publisher вводится сообщение по теме: Hello
На этом этапе еще нет приложения подписчика, поэтому необходимо:
Основные шаги, из которых складывается создание Приложения подписчика.
Шаг 1. Прежде всего, командой MQOPEN необходимо открыть очередь брокера для того, чтобы затем положить командное сообщение в соответствующую очередь.
Шаг 2. На этом шаге необходимо зарегистрировать интересы в виде темы и послать брокеру запрос на регистрацию подписки. Поскольку команды из основной программы будут посылаться брокеру довольно часто, необходимо разработать функцию SendBrokerCommand, одним из аргументов которой является командная строка для помещения в NameValueString командного сообщения. Эта функция SendBrokerCommand должна быть аналогичной по коду, как и для приложения Издателя.
Шаг 3. Теперь, когда подписчик зарегистрирован, можно ждать поступление публикаций в очередь подписчика, и как только они поступят, их можно прочесть командой MQGET. Первое, что необходимо сделать при получении сообщения, это проверить, что оно в нужном формате MQRFH.
Шаг 4. После распознавания формата MQRFH сообщения, можно выделить порцию наиболее интересного сообщения. В данном случае нет необходимости смотреть на строку NameValueString так как интересуют данные, которые следуют за этой строкой, они задаются указателем pUserData и могут быть напечатаны на экране или выведены в файл.
Шаг 5. На этом последнем шаге необходимо отказаться от регистрации и, как это делалось раньше на шаге 2, вызвать функцию SendBrokerCommand, добавив соответствующую команду для отказа от регистрации. Теперь, так же как и раньше, надо скомпилировать код и затем исправить ошибки компиляции. После этого программа готова для работы, ее можно выполнить:
subscriber TestTopic QM_broker Subscriber_queue
Этот запуск должен отобразить информацию об успешной регистрации у брокера. Если сообщение об успешной регистрации не поступило, то следует посмотреть сообщение об ошибке и исправить ее. После того как прошла успешная регистрация, можно попробовать получить сообщение по подписке. Для этого запустить программу publisher на тему TestTopic с сообщением, например, PublisherReady. В результате, в программе-подписчике должна появиться информация: PublisherReady.
Если этого не произойдет, то необходимо найти ошибку.
Получив успешно одну публикацию от одного издателя, можно расширить эксперимент и попробовать запустить много программ-издателей и программ-подписчиков. Каждой из них понадобиться своя очередь. Если сделать публикации на разные темы, можно ожидать получение определенных сообщений на экранах подписчиков, подписавшихся на соответствующие темы.
Интеграция приложений на основе WebSphere MQ
Channel-exit программы
Channel - exits программы выполняются канальными агентами. Эти программы первыми и последними встречают и провожают сообщения. Именно поэтому их чаще всего используют для шифрования, проверки идентификации и аутентификации сообщений в целях безопасности.Иногда возникает потребность применять Channel- exits программы, например, для того чтобы проследить прохождение сообщений и выполнить их логирование, выявить возникшие проблемы. Допустим, что стандартное ПО этого не делает, "вклиниваться" в него не представляется возможным, так как все входящие сообщения считывает из очереди программа-обработчик. В этом случае можно написать простую Channel- exits программу в виде библиотечной функции для UNIX или как DLL (Dynamic Linl Library) для Windows. Программе следует присвоить имя, к примеру, mqexit.dll с точкой входа MsgExit. Для работы программы, ее надо прописать в том канале, через который идут сообщения:
| Message Exit Name: | mqexit(MsgExit) |
| Message Exit Data: | \mydir\mqexit.ini |
С помощью программы RUNMQSC это может быть сделано командой:
alter chl(mychannel) chltype(mychannel_type) msgexit(' mqexit(MsgExit)') msgdata('\mydir\mqexit.ini')
Программа mqexit.dll и настроечный файл mqexit.ini помещаются в стандартной директории (mydir ) для Channel exits программ (для Windows это C:\Program Files\IBM\WebSphere MQ\Exits\, для UNIX HP_UX это /var/mqm/exits/, аналогичные пути существуют для других платформ).
Настроечный файл mqexit.ini может содержать имя лог файла, имя буферного файла для записи входящего сообщения; имя очереди, в которую перекладывается содержимое буферного файла; имя менеджера, ведь менеджеров может быть несколько на одном сервере.
В учебных целях стоит упростить задачу, не использовать mqexit.ini-файл и записать имя лог-файла непосредственно в Message Exit Data (например, C:\TEMP\mqexit.log), а с сообщениями пусть разбирается прежняя программа-обработчик, читающая входящие сообщения из очереди. При этом предполагается, что используется менеджер очередей по умолчанию. В этом случае программа mqexit.dll для Windows выглядит следующим образом.
Листинг 11.1. Листинг программы mqexit.c (html, txt)
В качестве комментария к программе надо отметить, что обязательным является соблюдение трех рекомендаций для Windows из документа [8]
- Intercommunication.
#include
LIBRARY mqexit DESCRIPTION 'Provides Retry and Channel exits' HEAPSIZE 4096 STACKSIZE 8192 EXPORTS ChannelExit
И после этого проходящие по каналу сообщения начинают записываться в файл, определенный в Message Exit Data, включая заголовок и данные сообщения. Скорость прохождения сообщений с использованием Channel exits программ уменьшится за счет команд записи на диск. Читателю предлагается исследовать самостоятельно во сколько раз измениться скорость работы программы и найти пути её повышения.
В заключение лекции следует отметить, что остались механизмы, которые не нашли отражение в этой книге и могли бы представлять интерес для читателя-программиста, а именно:
С этими вопросами читателю предлагается ознакомиться самостоятельно по документации.
Ключевым моментом интеграции приложений является использование WebSphere Business Integration Message Broker®, сокращенно WBI Message Broker или просто WBI Broker (ранее - IBM MQSeries Integrator®) для управления и преобразования потоков сообщений. Этот продукт компании IBM будет рассмотрен далее.
/*------------------------*/ /* remove space from data */ /*------------------------*/ for ( i = MQ_EXIT_DATA_LENGTH - 1; i > 0; i-- ) { if ( ini_filename??(i??) != ' ' && ini_filename??(i??) ) break; ini_filename??(i??) = 0; } } getINI(); void writer(long *lngth, char *bf) {
long msgsize; int n; FILE *fp; getINI(); fp = fopen(MsgBufFile, "ab"); msgsize = *lngth; n = fwrite(&msgsize, sizeof(msgsize), 1, fp); /* put record length */ n = fwrite(bf, msgsize, 1, fp); /* and message buffer */ fclose(fp); }
/*--------------------------------------------------------- getINI() - read information from INI file -----------------------------------------------------------*/ void getINI( void ) { FILE *ini_fp; char *ptr, *name_ptr; char field_val??(129??), Ini_s??(129??), fn??(129??); short len;
memset( Ini_s, 0, sizeof( Ini_s ) ); memset( field_val, 0, sizeof( field_val ) ); memset( MsgBufFile, 0, sizeof ( MsgBufFile ) ); memset( Channel_Logfile, 0, sizeof( Channel_Logfile ) );
if ( strlen( ini_filename ) ) /* if Channel Exit defined INI filename */ strcpy( fn, ini_filename ); /* use it */ else /* otherwise use default INI filename */ strcpy( fn, INI_FILENAME ); if ( (ini_fp = fopen( fn, "r" )) == NULL ) { fprintf(stderr, "\nUnable to open %s. Error #: %d", fn, errno ); return; }
/*-----------------------------*/ /* read the INI file until eof */ /*-----------------------------*/ while ( (ptr = fgets( Ini_s, sizeof(Ini_s) - 1, ini_fp )) != NULL ) { len = strlen( Ini_s ); if ( Ini_s??(len -1??) == LINEFEED ) Ini_s??(len-1??) = 0; /* null out '\n' */ if ( (name_ptr = strchr( Ini_s, EQUAL )) == NULL ) /* no '=' found */ continue; ptr = name_ptr + 1; *name_ptr = 0; /* set null for s[] */ strcpy( field_val, ptr ); fclose( ini_fp );
return; }
Листинг 11.1. Листинг программы mqexit.c
В качестве комментария к программе надо отметить, что обязательным является соблюдение трех рекомендаций для Windows из документа [8]
- Intercommunication.
#include
LIBRARY mqexit DESCRIPTION 'Provides Retry and Channel exits' HEAPSIZE 4096 STACKSIZE 8192 EXPORTS ChannelExit
И после этого проходящие по каналу сообщения начинают записываться в файл, определенный в Message Exit Data, включая заголовок и данные сообщения. Скорость прохождения сообщений с использованием Channel exits программ уменьшится за счет команд записи на диск. Читателю предлагается исследовать самостоятельно во сколько раз измениться скорость работы программы и найти пути её повышения.
В заключение лекции следует отметить, что остались механизмы, которые не нашли отражение в этой книге и могли бы представлять интерес для читателя-программиста, а именно:
С этими вопросами читателю предлагается ознакомиться самостоятельно по документации.
Ключевым моментом интеграции приложений является использование WebSphere Business Integration Message Broker®, сокращенно WBI Message Broker или просто WBI Broker (ранее - IBM MQSeries Integrator®) для управления и преобразования потоков сообщений. Этот продукт компании IBM будет рассмотрен далее.
| © 2003-2007 INTUIT.ru. Все права защищены. |
a sample message exit function
|
/* Листинг программы mqexit.dll */ /************************************************************************/ /* Program name: mqexit */ /* Description: This is a sample message exit function record all messages */ /* This function will work on any channels, e.g. send, receive, requester, etc. */ /* This function logs all channel activities into the Channel Log file. */ /* Please see Intercommunication documentation to specify the Channel Message Exit */ /* Authors: Vladimir Makushkin, Moscow, Russia */ /* email: vmakushkin@mail.ru */ /* Disclaimer: this program has been tested under HP_UX and Windows to the */ /* authors' satisfaction. You may use this program at your own risk. Author are not */ /* responsible for any unexpected results generated by this program. */ /************************************************************************/ /* standard headers */ #include /*------------------------*/ /* remove space from data */ /*------------------------*/ for ( i = MQ_EXIT_DATA_LENGTH - 1; i > 0; i-- ) { if ( ini_filename??(i??) != ' ' && ini_filename??(i??) ) break; ini_filename??(i??) = 0; } } getINI(); void writer(long *lngth, char *bf) { long msgsize; int n; FILE *fp; getINI(); fp = fopen(MsgBufFile, "ab"); msgsize = *lngth; n = fwrite(&msgsize, sizeof(msgsize), 1, fp); /* put record length */ n = fwrite(bf, msgsize, 1, fp); /* and message buffer */ fclose(fp); } /*--------------------------------------------------------- getINI() - read information from INI file -----------------------------------------------------------*/ void getINI( void ) { FILE *ini_fp; char *ptr, *name_ptr; char field_val??(129??), Ini_s??(129??), fn??(129??); short len; memset( Ini_s, 0, sizeof( Ini_s ) ); memset( field_val, 0, sizeof( field_val ) ); memset( MsgBufFile, 0, sizeof ( MsgBufFile ) ); memset( Channel_Logfile, 0, sizeof( Channel_Logfile ) ); if ( strlen( ini_filename ) ) /* if Channel Exit defined INI filename */ strcpy( fn, ini_filename ); /* use it */ else /* otherwise use default INI filename */ strcpy( fn, INI_FILENAME ); if ( (ini_fp = fopen( fn, "r" )) == NULL ) { fprintf(stderr, "\nUnable to open %s. Error #: %d", fn, errno ); return; } /*-----------------------------*/ /* read the INI file until eof */ /*-----------------------------*/ while ( (ptr = fgets( Ini_s, sizeof(Ini_s) - 1, ini_fp )) != NULL ) { len = strlen( Ini_s ); if ( Ini_s??(len -1??) == LINEFEED ) Ini_s??(len-1??) = 0; /* null out '\n' */ if ( (name_ptr = strchr( Ini_s, EQUAL )) == NULL ) /* no '=' found */ continue; ptr = name_ptr + 1; *name_ptr = 0; /* set null for s[] */ strcpy( field_val, ptr ); fclose( ini_fp ); return; } |
| Листинг 11.1. Листинг программы mqexit.c |
| Закрыть окно |
strncpy( ini_filename, pChannelExitParams->ExitData, MQ_EXIT_DATA_LENGTH );
/*------------------------*/
/* remove space from data */
/*------------------------*/
for ( i = MQ_EXIT_DATA_LENGTH - 1; i > 0; i-- )
{
if ( ini_filename??(i??) != ' ' && ini_filename??(i??) )
break;
ini_filename??(i??) = 0;
}
}
getINI();
void writer(long *lngth, char *bf)
{
long msgsize;
int n;
FILE *fp;
getINI();
fp = fopen(MsgBufFile, "ab");
msgsize = *lngth;
n = fwrite(&msgsize, sizeof(msgsize), 1, fp); /* put record length */
n = fwrite(bf, msgsize, 1, fp); /* and message buffer */
fclose(fp);
}
/*---------------------------------------------------------
getINI() - read information from INI file
-----------------------------------------------------------*/
void getINI( void )
{
FILE *ini_fp;
char *ptr, *name_ptr;
char field_val??(129??), Ini_s??(129??), fn??(129??);
short len;
memset( Ini_s, 0, sizeof( Ini_s ) );
memset( field_val, 0, sizeof( field_val ) );
memset( MsgBufFile, 0, sizeof ( MsgBufFile ) );
memset( Channel_Logfile, 0, sizeof( Channel_Logfile ) );
if ( strlen( ini_filename ) ) /* if Channel Exit defined INI filename */
strcpy( fn, ini_filename ); /* use it */
else /* otherwise use default INI filename */
strcpy( fn, INI_FILENAME );
if ( (ini_fp = fopen( fn, "r" )) == NULL )
{
fprintf(stderr, "\nUnable to open %s. Error #: %d", fn, errno );
return;
}
/*-----------------------------*/
/* read the INI file until eof */
/*-----------------------------*/
while ( (ptr = fgets( Ini_s, sizeof(Ini_s) - 1, ini_fp )) != NULL )
{
len = strlen( Ini_s );
if ( Ini_s??(len -1??) == LINEFEED )
Ini_s??(len-1??) = 0; /* null out '\n' */
if ( (name_ptr = strchr( Ini_s, EQUAL )) == NULL ) /* no '=' found */
continue;
ptr = name_ptr + 1;
*name_ptr = 0; /* set null for s[] */
strcpy( field_val, ptr );
fclose( ini_fp );
return;
}
Группировка и сегментация сообщений
До настоящего момента говорилось о физических сообщениях WebSphere MQ, и этого было вполне достаточно. Обычные сообщения длиной до 4Мб и сообщения максимальной длины в 100Мбт покрывают потребности любых приложений на 95%. Необходимость использования сверхбольших сообщений (> 100Мбт) или ограничения в приложениях на длину сообщений приводят к необходимости использовать понятия физических и логических сообщений, механизмы группирования и сегментации сообщений.Физическое сообщение - наименьший блок информации, который может быть размещен в очереди. Одно физическое сообщение принято называть сегментом.
Логическое сообщение это либо отдельный блок информации приложения, либо один или несколько сегментов.
Группа сообщений это одно или несколько логических сообщений. Сегментация сообщений обычно используется, когда требуется работа с сообщениями, которые слишком большие для менеджера, очереди, либо приложения. Группы сообщений,как правило, применяются в следующих случаях:
Пусть необходимо объединить в группу три сообщения. Для этого в дескрипторе сообщений полю MQMD_GroupId (24 байта) нужно присвоить уникальный идентификатор и записать его в каждом сообщении. Следующему полю MQMD_MsgSeqNumber присвоить значения 1, 2 и 3 для первого, второго и третьего сообщений, соответственно, как показано это на рис.11.1. Если сообщение не включено в группу, то для него GroupId будет NULL (MQGI_NONE), а в MsgSeqNumber будет значение 1. WebSphere MQ может автоматизировать присвоение MsgSeqNumber во время выполнения функции MQPUT, если в PMO задана опция MQPMO_LOGICAL_ORDER. В этом случае также понадобится установить значение в новое поле дескриптора сообщений: MQMD.MsgFlags, которое может иметь значения MQMF_MSG_IN_GROUP и MQMF_LAST_MSG_IN_GROUP. Если в GroupId было установлено значение MQGI_NONE, то для GroupId будет сгенерирован новый уникальный идентификатор при использовании MQPMO_LOGICAL_ORDER. И еще одно правило для вывода группы сообщений: свойства сообщений PERSISTENCE и NOT_PERSISTENCE не должны перемешиваться в одной группе.
Для пояснения изложенного следует привести фрагмент программы, использующей вывод сообщений в виде группы.
if ((CompCode == MQCC_OK) || (CompCode == MQCC_WARNING)) { pmo.Options = MQPMO_LOGICAL_ORDER + MQPMO_SYNCPOINT ; memcpy(md.GroupId, "1", sizeof(md.GroupId)); memcpy(md. MsgFlags, "MQMF_MSG_IN_GROUP", sizeof(md. MsgFlags));
//memcpy(md.MsgSeqNumber, 1, // sizeof(md.MsgSeqNumber)); //memcpy(md.MsgFlags, MQMF_SEGMENT, // sizeof(md.MsgFlags));
/* блок формирования buffer */ MQPUT1(Hcon, &odR, &md, &pmo, messlen, buffer, &CompCode, &Reason); if (Reason != MQRC_NONE) printf("MQPUT1 ended with reason code %ld\n", Reason); } /* конец цикла чтения поступающих сообщений */
memcpy(md. MsgFlags, "MQMF_ LAST_MSG_IN_GROUP", sizeof(md. MsgFlags));
/* блок формирования buffer */ MQPUT1(Hcon, &odR, &md, &pmo, messlen, buffer, &CompCode, &Reason); if (Reason != MQRC_NONE) printf("MQPUT1 ended with reason code %ld\n", Reason);
Рис. 11.1. Группа сообщений и сегментация сообщения
Процесс извлечения группы логических сообщений из очереди командой MQGET во многом будет зависеть от значений, заданных в опции GMO. Если задать значение MQGMO_ALL_MSGS_AVAILABLE, то сообщения будут доступны для чтения только, когда все сообщения группы поступят в очередь. Если задана опция MQGMO_LOGICAL_ORDER, то сообщения можно извлекать в порядке, определяемом MsgSeqNumber и только по одному сообщению из группы. Если опция MQGMO_LOGICAL_ORDER не задана, то приложение должно выбирать сообщения двумя способами:
Например, опция CORREL_ID означает, что должно выбираться сообщение, корреляционный идентификатор которого, соответствует значению поля CorrelId параметра MsgDesc функции MQGET. Это согласование является дополнением к любому другому соответствию, заданному в MatchOption. Если корреляционный идентификатор есть MQCI_NONE, то это равносильно тому, что опция MQMO_MATCH_CORREL_ID не определена.
Теперь следует дать расширенное определение сегмента сообщения. Сегментом сообщения называется физическое сообщение, идентифицируемое тройкой: GroupId, MsgSeqNumber и Offset. Из лекции 8 известно, что Offset это поле формата MQLONG в структурах MQOD и MQMD. Таким образом, одно логическое сообщение может состоять из нескольких сегментов, как показано на рис.11.1.
Разбиение на сегменты (сегментация) и обратная процедура, называемая реассемблированием (reassembly) может осуществляться менеджером очередей или приложением. Для начала следует рассмотреть, как это осуществляет менеджер очередей. Если дескриптор сообщения имеет в поле MsgFlag значение MQMF_SEGMENTATION_ALLOWED, и менеджер очередей определил, что сообщение является слишком большим для его MaxMsgLength или для значения параметра MaxMsgLength для очереди, то тогда менеджер осуществляет сегментацию. Никаких предположений о том, как выполняется разбиение данных, сделано быть не может.
Реассемблирование с помощью менеджера осуществляется, если при чтении сообщений командой MQGET была задана GMO-опция: MQGMO_COMPLETE_MESSAGE. В этом случае извлекаются все сегменты, и только полное логическое сообщение помещается в программный буфер. Следует быть внимательным при задании преобразования данных в sender-канале. Поскольку не все сегменты приходят одновременно, преобразование данных в канале в связи с разными кодовыми страницами может привести к ошибкам и рекомендуется задавать предобработку (UOW - unit of work) с помощью менеджера (опция MQRC_UOW_AVAILABLE) или приложения (опция MQRC_UOW_NOT_AVAILABLE).
Сегментация с помощью приложения возможна в двух случаях:
Для сегментации с помощью приложения необходимо включить для функции MQPUT опцию MQPMO_LOGICAL_ORDER и проследить за правильным включением в поле MsgFlags флажков MQMF_SEGMENT и MQMF_LAST_SEGMENT. Менеджер очередей позаботиться о назначении и поддержании GroupId, MsgSeqNumber и Offset.
Реассемблирование с помощью приложения осуществляется, если при чтении сообщений командой MQGET была задана GMO-опция: MQGMO_COMPLETE_MESSAGE и флажок MsgFlags имеет значение MQMF_SEGMENTATION_ALLOWED. В этом случае приложение извлекает сегменты самостоятельно в зависимости от ограничений на свой размер буфера. Опции MQGMO_ALL_MSGS_AVAILABLE и MQGMO_ALL_SEGMENTS_AVAILABLE позволят начать работу, если все сообщения или все сегменты поступят в очередь. Как только первое сообщение поступит в очередь, можно использовать MQGMO_LOGICAL_ORDER опцию, чтобы быть уверенным, что все последующие сегменты логического сообщения будут обработаны. Если опция MQGMO_LOGICAL_ORDER не задана, то приложение может выбирать сообщения на основе опций соответствия MatchOption, как это делалось для групп:
Приложение может определить окончание работы с сегментом с помощью возвращаемого MQGET значения поля MQGMO.SegmentStatus, которое может принимать следующие значения: MQSS_SEGMENT, MQSS_LAST_SEGMENT, MQSS_NOT_A_SEGMENT.
В завершение раздела можно привести примеры использования функций MQPUT и MQGET для вывода и чтения логических сообщений в соответствии с их структурой, указанной на рис.11.1.
/* пример использования функции MQPUT */ PMO.Options = MQGMO_LOGICAL_ORDER + MQGMO_SYNCPOINT
/* помещаем в очередь первое логическое сообщение*/ MQPUT (MQMF_MSG_IN GROUP + MQMF_SEGMENT) MQPUT (MQMF_MSG_IN GROUP + MQMF_SEGMENT) MQPUT (MQMF_MSG_IN GROUP + MQMF_LAST_SEGMENT)
/* помещаем в очередь второе логическое сообщение */ MQPUT (MQMF_MSG_IN GROUP + MQMFSEGMENT)
/* помещаем в очередь третье логическое сообщение */ MQPUT (MQMF_LAST_MSG_IN GROUP + MQMF_SEGMENT) MQPUT (MQMF_ LAST_MSG_IN GROUP + MQMF_LAST_SEGMENT) MQCMIT
/* пример использования функции MQGET */ GMO.Options = MQGMO_LOGICAL_ORDER + MQGMO_SYNCPOINT + MQGMO_ALL_MSGS_AVAILABLE + MQGMO_WAIT Do while (Not MQGS_LAST_MSG_IN GROUP and Not MQSS_LAST_SEGMENT) MQGET (........) /* обработка сегмента или законченного логического сообщения */ End MQCMIT
Модификация объектов
Характеристики объектов WebSphere MQ определяются в момент создания, но иногда их необходимо модифицировать, например, изменив приоритет сообщений при помещении их в очередь (Default Priority) или максимально допустимое количество сообщений в очереди (Maximum Queue Depth). Модификация объектов WebSphere MQ требуется, в частности, при восстановлении опций очередей Put Messages и Get Messages в состояние Allowed, а также параметров триггеринга, извлечении статистических данных (Message Count и т.п.). Необходимость работы с функциями MQINQ и MQSET, предназначенными для этих целей, возникает не так часто, но без этого иногда трудно обойтись.Функция MQINQ позволяет извлечь атрибуты любой очереди, процесса, менеджера или списка кластеров namelist. MQSET дает возможность изменить эти параметры, но только для очереди. Обе функции используют массивы идентификаторов (selectors), в которых указывается, какие характеристики объектов должны быть извлечены или изменены. Имена идентификаторов имеют префиксы: MQCA_ для символьных данных (например, имя очереди) и MQIA_ для числовых данных (например, Maximum Queue Depth).
Допустим, для некоторой очереди необходимо определить характеристики: количество сообщений в очереди, максимальное количество сообщений, имя очереди и ее описание.
Формат команды:
MQINQ (Hconn, Hobj, SelectorCount, Selectors, IntAttrCount, IntAttrs, CharAttrLength, CharAttrs, CompCode, Reason)
Очередь должна быть открыта и Hconn, Hobj известны.
Пусть общее количество идентификаторов MQLONG SelectorCount = 4; они должны быть перечислены в массиве MQLONG Selectors[4];
Selectors [0] = MQIA_CURRENT_Q_DEPTH; Selectors [1] = MQIA_MAX_Q_DEPTH; Selectors [2] = MQCA_Q_NAME; Selectors [3] = MQCA_Q_DESC;
Число цифровых атрибутов задается в MQLONG IntAttrCount = 2; они должны вернуться в массив MQLONG IntAttrs [2]; Длина затребованных символьных данных MQLONG CharAttrLength = 112; (48 для MQCA_Q_NAME и 64 для MQCA_Q_DESC) и они должны вернуться в массив CHAR CharAttrs[112] = ""; Теперь можно выполнять MQINQ. Не стоит забывать одно важное правило: цифровые и символьные характеристики следуют в массивах IntAttrs и CharAttrs в том порядке, как они перечислены в массиве Selectors.
В случае, когда программа rewriter (см. лекцию 8), запускается как триггер, при поступлении сообщения в очередь INPUT.Q, использовать ini-файл неудобно и гораздо проще задать необходимые параметры в свойствах очереди. Для этого в свойствах очереди INPUT.Q в закладке Triggering указывается:
Trigger Control = On Initiation Queue Name = INPUT_INIT.Q Process Name = rewriter
а для процесса rewriter определяется
PROCESS_USER_DATA = OUTPUT.Q /* queue output */ PROCESS_APPL_ID = "C:\rewriter\rewriter.exe" PROCESS_ENV_DATA = rewriter.log /* имя лог-файла не более 24 символов */
Теперь в программе легко можно извлечь все необходимые параметры с помощью MQINQ. После завершения работы программы очередь инициализации следует очистить. Это делает следующий фрагмент кода:
MQLONG Select[1]; /* attribute selectors */ MQLONG SelectValue[1]; /* value attribute selectors */ MQLONG char_count; char queueinitname[48] = ""; int queuenamelen;
Select[0] = MQCA_INITIATION_Q_NAME; /* attribute selectors */ queuenamelen = 0; char_count = 48; MQINQ(Hcon, Hobj, 1, Select, 0, NULL, char_count, queueinitname, &CompCode, &Reason); queuenamelen = strlen(queueinitname) - 1; queueinitname[queuenamelen] = ' '; strncpy(odI.ObjectName, queueinitname, 24); O_options = MQOO_INPUT_SHARED + MQOO_FAIL_IF_QUIESCING; MQOPEN(Hcon, &odI, O_options, &Hinq, &CompCode, &Reason); if (Reason != MQRC_NONE) { printf("MQOPEN (input) ended with reason code %ld\n", Reason); } if (CompCode == MQCC_FAILED) { exit(Reason); } memcpy(md.MsgId, MQMI_NONE, sizeof(md.MsgId)); memcpy(md.CorrelId, MQMI_NONE, sizeof(md.CorrelId)); while (CompCode == MQCC_OK) { gmo.Options = MQGMO_ACCEPT_TRUNCATED_MSG + MQGMO_WAIT; gmo.WaitInterval = 1; memcpy(md.MsgId, MQMI_NONE, sizeof(md.MsgId)); memcpy(md.CorrelId, MQMI_NONE, sizeof(md.CorrelId)); buflen = sizeof(buffer) - 1; MQGET(Hcon, Hinq, &md, &gmo, buflen, buffer, &messlen, &CompCode, &Reason); // printf("Inituation queue clear with // reason code %ld and CompCode %ld\n", // Reason, CompCode); } CompCode = MQCC_OK ;
В этом фрагменте MQINQ используется для извлечения только одного параметра: имени очереди инициализации. Очистка этой очереди делается командой MQGET до тех пор, пока очередь не будет пуста.
Функция MQSET по формату полностью аналогична MQINQ, разница между ними заключается только в направлении потоков данных. В качестве примера можно рассмотреть работу триггера с условиями Trigger Type = First и Trigger Depth = 1. При срабатывании триггера флажок из состояния Trigger Control = On переходит в состояние Trigger Control = Off и его надо восстанавливать. Это делает следующий фрагмент кода:
Select[0] = MQIA_TRIGGER_CONTROL; /* attribute selectors */ SelectValue[0] = 1 ; MQSET(Hcon, Hobj, 1, Select, 1, SelectValue, 0, NULL, &CompCode, &Reason);
Заключительный вывод по разделу: функция MQINQ позволяет извлечь атрибуты любой очереди, процесса, менеджера или списка кластеров namelist, а функция MQSET - изменить эти параметры, но только для очереди.
Работа с MsgId и CorrelId
Теперь полезно изучить способы контроля доставки сообщений, тем более что для этого существуют специальные поля в дескрипторе сообщений: MsgId и CorrelId. Например, некоторое приложение отправляет запросы на обработку в очередь Queue1 и ожидает уведомления о доставке в очереди ReplyToQ = Queue2. Совершенно очевидно, что уведомления о доставке не обязаны появиться в очереди Queue2 в той же последовательности, в какой отправлялись запросы в очередь Queue1. Как же в таком случае отслеживать доставку сообщений?Другой пример, приложение отправляет запросы в разные системы, в частности, по банковским счетам клиента и по проверке его кредитной истории и ожидает получить ответ от запрашиваемых систем в одну и ту же очередь для всех клиентов. Как же идентифицировать поступающие ответы? Самое простое - использовать идентификаторы MsgId и CorrelId, которые являются уникальными для каждого сообщения и создаются на основе времени выполнения команды MQPUT. Идентификаторы MsgId и CorrelId создаются менеджером, если они установлены в NULL, либо заданы опции MQPMO_NEW_MSG_ID и/или MQPMO_NEW_CORREL_ID; в противном случае, MsgId и CorrelId создаются приложением.
Таким образом, задавая значения MsgId и CorrelId при выполнении MQPUT, появляется возможность автоматически получать значения MsgId и CorrelId при чтении командой MQGET. При этом не надо забывать, что в цикле считывания перед командой MQGET следует ставить обнуление этих переменных (MsgId=MQMI_NONE и CorrelId=MQCI_NONE), иначе можно получить ошибку считывания сообщений из очереди MQRC_NO_MSG_AVAILABLE, несмотря на то, что сообщения в очереди имеются.
Рассмотрим на примере, как работает MQGET с MsgId и CorrelId на практике. Пусть в некоторую очередь поступили сообщения в определенном порядке, как указано в таблице ниже.
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 3 |
| 4 | 2 | 1 |
| 5 | 2 | 2 |
| 6 | 3 | 1 |
Теперь варьируя MsgId и CorrelId, можно читать самые разные сообщения.
MQGET (MSGID= MQMI_NONE, CORRELID= MQCI_NONE) читает первое доступное сообщение независимо от MsgId и CorrelId, то есть сообщение 1.
MQGET (MSGID= MQMI_NONE, CORRELID= 3) может прочитать только одно сообщение, имеющее значение CorrelId = 3, это сообщение 3.
MQGET (MSGID= 2, CORRELID= MQCI_NONE) читает первое сообщение со значением MsgId = 2, это сообщение 4.
MQGET (MSGID= 2, CORRELID= 2) может прочитать только одно сообщение, имеющее уникальное сочетание MsgId = 4 и CorrelId = 2, это сообщение 5.
Таким образом, если никакие другие сообщения не поступят в очередь, то в очереди после четырех MQGET останутся 2 сообщения. Здесь уместен вопрос о производительности работы менеджера очередей при таком поиске сообщений. Если число сообщений в очереди не превышает 100, то время поиска будет незначительным, оно практически не зависит от числа сообщений. Но если число сообщений в очереди превысит 1000, то менеджер будет сканировать очередь и время поиска будет заметным. На OS/390 MQSeries администратор может определить MsgId или CorrelId (но не одновременно) как индекс и это существенно ускорит поиск нужного сообщения в очереди. Следует также отметить, что на других платформах (AS/400, HP_UX, AIX, Sun Solaris, Windows) в версии 5.3 WebSphere MQ можно использовать опции соответствия MatchOption: MQMO_MATCH_MSG_ID и MQMO_MATCH_CORREL_ID. Если эти опции соответствия не будут определены, то MsgId и CorrelId будут игнорироваться, как если бы использовались опции MQMI_NONE и MQCI_NONE и будет извлекаться очередное сообщение.
Сформулируем одно общее правило при разработке программ с контролем доставки сообщений с помощью MsgId и CorrelId: если приложение перемещает сообщение из входной очереди в выходную, то MsgId входного сообщения перемещается в CorrelId выходного сообщения и создается новый уникальный идентификатор MsgId выходного сообщения. На уровне псевдокода это правило можно записать следующим образом:
INPUT_MSG_DESC.MsgId = MQMI_NONE; INPUT_MSG_DESC.CorrelId = MQCI_NONE; MQGET (..........); /* Обработка входного сообщения */ OUT_MSG_DESC.MsgId = MQMI_NONE; OUT_MSG_DESC.CorrelId = INPUT_MSG_DESC.MsgId; MQPUT (..........);
Разрабатывая логику в цепи программ- обработчиков сообщений на разных платформах следует стремиться к тому, чтобы CorrelId содержал MsgId исходного запроса, а MsgId выходного сообщения содержал уникальный идентификатор, полученный наиболее важной в функциональном смысле выходной программой. На основе такой логики легко получить подтверждение на выходе, что исходный запрос был отработан, и промежуточные программы проставили свой MsgId в выходном сообщении. Это позволяет осуществить контроль времени прохождения запроса и получения сообщения-отчета.
В завершение раздела, уж если речь пошла о контроле доставки сообщений, необходимо отметить возможность использования полей context (контекст) в дескрипторе сообщения для контроля авторизации пользователя и обеспечения безопасности. Группа полей context состоит из 8 полей, их значения по умолчанию приводятся в таблице ниже.
| UserIdentifier | CHAR12 | Имя пользователя | PutAppName | CHAR28 | Имя приложения |
| AccountingToken | BYTE32 | Учетный номер приложения-отправителя | PutDate | CHAR8 | YYYYMMDD |
| AppIdentityData | CHAR32 | Пробелы | PutTime | CHAR8 | HHMMSSTH |
| PutApplType | LONG | UNIX и т.п. | AppOriginData | CHAR4 | пробелы |
Интеграция приложений на основе WebSphere MQ
Архитектура и функции интеграционного решения
Топология интеграционного решения отражает различные способы взаимодействия приложений (рис.12.1). Среди основных топологий можно выделить простые соединения точка-точка, шлюзы и шины. Соединение точка-точка означает, что интегрируемые приложения устанавливают прямые связи друг с другом. Обычно на начальной стадии любого интеграционного проекта именно соединение точка-точка используется, как наиболее простой подход. При этом для взаимодействующих приложений необходимо, во-первых, знать точную адресную информацию о партнере и, во-вторых, уметь осуществлять преобразования между форматами данных, используемых партнерами. Интеграция типа точка-точка часто означает разработку и встраивание дополнительного ПО как минимум для одного, а чаще для обоих взаимодействующих приложений.Для упрощения разработки дополнительного ПО часто используются специализированные выделенные программные компоненты: адаптеры и брокеры. Адаптеры обеспечивают преобразование специфических интерфейсов и данных конкретного приложения в интерфейсы и данные стандартной интеграционной среды. Настройка интерфейсов, адресной информации и процедур трансформации вместо написания кода, позволяют ускорить внедрение интеграционного решения. Типичными примерами являются адаптеры для распространенных прикладных систем, таких как SAP R/3, баз данных, электронной почты Lotus Notes, специализированных систем передачи информации EDI, ACORD, SWIFT.
Рис. 12.1. Способы соединения приложений
Шлюз или централизованный брокер возникает как центральный узел, к которому обращаются интегрируемые системы и приложения. Через него направляются потоки сообщений и данных с этих систем. Шлюз перераспределяет, обрабатывает и направляет такие потоки. Использование шлюза позволяет возложить на него функции адресации и трансформации передаваемых данных, причем гораздо более сложные, чем в случае прямого соединения или применения адаптеров. Централизованная реализация функций обработки передаваемой информации и данных ведет к выделению репозитория общих интеграционных правил, что позволяет эффективно и динамически сопрягать приложения в единую среду.
Существует еще один вариант соединения приложений - топология шины, когда приложения используют многочисленные подсоединения к единой среде обмена информацией. Топология шины является более гибкой, чем централизованный брокер, и не имеет единой критической для сбоев и производительности точки. В то же время реализация топологии типа шины часто предусматривает более жесткую спецификацию внутренних форматов и данных, которыми обмениваются через шину взаимодействующие приложения и тем самым накладывает определенные ограничения.
Функции интеграционного решения. Любое интеграционное решение служит для выполнения четырех главных технологических функций: подключение к интеграционной среде, транспортировка, трансформация данных и процессы обработки.
Подключение. Эта функция описывает механизм участия приложений в интеграционной среде. Любое развитое предприятие располагает большим набором самостоятельно разработанных и готовых приложений, которые необходимо интегрировать. Подключение определяет способ, с помощью которого интеграционная среда поддерживает связь с приложением, а также метод, посредством которого приложения общаются с интеграционной средой.
Компоненты подключения называются "адаптерами" (рис.12.2). Это предварительно созданные программные компоненты, которые обеспечивают коммуникацию со специфическими приложениями, такими, как SAP R/3, и технологиями, например, с СУБД Oracle или MS SQL Server. Преимущества этих адаптеров состоят в том, что они позволяют уменьшить объем времени и ресурсов, затрачиваемых на поддержку коммуникации с приложениями и системами, поскольку эти функции уже встроены в данное программное обеспечение. В составе интеграционной среды должен быть набор адаптеров для различных приложений и технологий. В качестве составной части адаптеры должны иметь инструментарий разработки, который позволяет создавать новые адаптеры и настраивать старые.
Адаптеры дают возможность соединяться с приложениями через собственный программный интерфейс API приложения, либо с помощью технологий, использующих стандартизованные методы доступа (например, интерфейс JDBC вызывает различные базы данных Oracle, MS SQL). Адаптеры включают средства управления событиями, которые уведомляют оболочку интеграции о произошедшем в приложении событии. Кроме того, адаптеры управляют обработкой событий между абонентскими приложениями на основе модели публикации-подписки. В зависимости от выбранной модели развертывания, они могут также управлять функциями преобразования (преобразованием в/из конкретного формата, используемого организацией для бизнес-объектов). Все адаптеры характеризуются высокой эффективностью и большой функциональностью, которая способна удовлетворить самые сложные требования. Все адаптеры включают стандартизованные средства управления ошибками, инструменты для регистрации и отслеживания.
Рис. 12.2. Компоненты интеграционного адаптера
Транспортировка. Для того чтобы обеспечить перемещение информации, как между приложениями, так и между приложениями и интеграционной инфраструктурой, необходим механизм, который бы осуществлял безопасный и защищенный перенос данных между сетями. Современное предприятие располагает большим числом сетевых соединений, через которые требуется обеспечить перенос информации. Транспортировка определяет защищенный способ однократной гарантированной доставки информации из любого источника в любой пункт назначения.
Эта функция поддерживает все другие службы, поскольку она гарантирует однократную доставку правильной информации нужному приложению. Для поддержки этой транспортной функциональности интеграционная платформа может использовать различные механизмы, однако наиболее эффективной и гибкой технологией являются очереди сообщений, такие как WebSphere MQ.
Транспортные компоненты берут на себя заботу о сетевых интерфейсах, гарантируют "однократную" доставку сообщений, взаимодействуют с коммуникационными протоколами, динамически распределяют рабочую нагрузку среди доступных ресурсов, управляют восстановлением после низкоуровневых системных сбоев и помогают обеспечить портативность собственных программ. Такая технология интеграции поддерживает более высокий уровень функциональности при условии более безопасного перемещения данных по сети.
Преимущества использования очередей сообщений для организации интеграционного транспорта заключаются в том, что они обеспечивают гарантированную однократную доставку информации, а также обладают высоким быстродействием и чрезвычайной надежностью. Все эти преимущества помогают поддерживать эффективность среды интеграции.
Преобразование. Любая оболочка интеграции должна работать с информацией, которая содержится в разных структурах и представлена в различных форматах. В качестве примера можно привести случай, когда формат данных заказчика в одном приложении разительно отличается от формата, поддерживаемого другим приложением, которое нужно обновить с помощью этих данных.
Оболочка интеграции должна располагать средствами для преобразования форматов информации из одного типа данных в другой.
Интеграционная среда должна иметь в своем составе встроенные функции преобразования, которые помогают сократить затраты времени и ресурсов на поддержание и обслуживание оболочки интеграции.
Встроенный механизм преобразования обеспечивает значительное сокращение затрат времени и ресурсов на развертывание и поддержание оболочки интеграции.
Процессы обработки. Среда интеграции должна определить правила, по которым выполняются операции между приложениями, а также время и порядок их совершения. Эти правила задают тип операций между любым количеством приложений, определяют необходимость сбора дополнительной информации, проверки достоверности и контроля целостности данных, а также управляют обработкой любых ошибок.
Интеграционная среда должна поддерживать процессы обработки информации как систему управления всеми операциями между приложениями, пользователями и процессами. Интеграционная среда может предоставлять шаблоны стандартизованных процессов, которые поддерживают широкий диапазон специфических и единых интеграционных требований - поставляемых в виде настраиваемых или реконфигурируемых шаблонов. Эти шаблоны могут использовать типичные структуры бизнес - данных. Это означает, что любой шаблон может управлять операциями между любыми приложениями.
В тех случаях, когда отсутствуют готовые шаблоны процессов интеграции для всех необходимых бизнес-процессов, или существующие решения не удовлетворяют требованиям, необходим инструментарий, позволяющий проектировать и реализовывать бизнес-процессы. Эти средства дают возможность значительно снизить время, усилия и ресурсы, необходимые для настройки, изменения или создания новых процессов интеграции, удовлетворяющих всем требованиям.
Одной из важных характеристик процессов обработки является возможность обработки сбоев. Если сбой происходит при выполнении процесса взаимодействия приложений, не использующего транзакции, процесс может внести ошибку в протокол и завершить работу. Если сбой случается в интеграционном процессе, построенном на основе транзакций, выполняется откат процесса, что позволяет сохранить исходные данные всех задействованных в процессе приложений и баз данных.
В качестве примера процесса можно привести синхронизацию информации о заказчике. Под этим подразумевается синхронизация информации о заказчике между любым числом приложений. Функции предлагаемого решения способны обнаружить изменение данных заказчика в исходной системе, проверить доступность целевой системы, необходимость отправки этой информации в целевую систему, существование специфического заказчика, внести изменения и получить уведомление о произошедших изменениях. В случае если изменения не произошло, выполняется обработка ошибки.
Интеграционный брокер и требования к его функциональности
Существует несколько различных способов реализации вычислительного обрабатывающего процесса для интеграционных задач. Можно использовать универсальные решения, такие как серверы приложений общего назначения, специализированные пакеты, интеграционные брокеры. Интеграционные брокеры представляют собой решение для взаимодействия приложений через центральный промежуточный шлюз, поддерживающий интеллектуальную обработку и распределение данных между приложениями.Роль брокера в интеграционной среде, основанной на передаче сообщений, можно образно выразить как, например, роль почтамта для обычной почты. Почтовые отправления сортируются и регистрируются, адресная информация проверяется, и, наконец, распределяется для дальнейшей отправки адресатам. Причины использовать такой промежуточный узел в сложной вычислительной среде могут быть самыми разными. Приложение в конечной точки может не знать, а иногда не обязано знать точной адресной информации о системе-адресате. Реальная информация может меняться, системы могут добавляться или выбывать из эксплуатации. Изоляция систем друг от друга может иметь место также по причине безопасности. Системы, которые могут быть заинтересованы в приходящих данных или которые нужно вовлечь в обработку присылаемой информации, могут иметь разные интерфейсы. Брокер в этом плане, предоставляет среду для встраивания компонентов с различными интерфейсами. Масштабы системы и необходимая пропускная способность могут потребовать высокопроизводительного масштабируемого обрабатывающего ядра.
Брокер возникает, как промежуточный сервер в интеграционной транспортной среде (рис.12.3). Он занимается, во-первых, обработкой потоков сообщений и передаваемых данных, во-вторых, исполнением вызовов и обращения по различным интерфейсам. Брокер перераспределяет, обрабатывает и направляет потоки информации, данных и сообщений между интегрируемыми системами. Вычислительное ядро брокера должно поддерживать разнообразную вычислительную обработку, анализ и принятие решений на основании проходящих через брокер данных и бизнес-правил, хранимых брокером. При использовании брокера, правила интеграции систем выносятся из закрытого кода конкретных прикладных систем в централизованный репозиторий бизнес - правил. Использование централизованного репозитория правил, описывающих как осуществляется взаимодействие различных систем, означает возможность глобального применения этих правил ко всем взаимодействующим системам, открытость и простоту изменения правил при смене внешних условий, быстроту разработки.
Рис. 12.3. Компоненты WebSphere Message Broker
Преобразование форматов данных. Существенной функциональной особенностью брокера является возможность работы с данными, находящимися в различных форматах. Данные, передаваемые между системами, могут быть в различных форматах, в частности, открытые стандартизованные форматы типа документов XML, специфические для конкретной индустрии или области применения форматы типа EDI или SWIFT, либо форматы, которые относятся к конкретному прикладному пакету типа SAP R/3 или уникальному, кем-то разработанному приложению. Брокер должен обеспечить совместимость форматов для всех участвующих в обмене сторон и, соответственно, уметь оперировать данными в форматах самых разных типов.
Маршрутизация информации и данных. Передача информации от одного приложения к другому иногда может базироваться на методе прямой адресации, когда посылающее приложение явно знает и указывает своего корреспондента. Однако случается, что адресная информация неизвестна отправителю, может меняться, должна быть определена из содержания передаваемого сообщения, либо быть получена в момент обработки из внешних данных. В таких ситуациях брокер может выступать интеллектуальным маршрутизатором потоков данных. Анализируя адресную, контекстную и прикладную часть информации, используя бизнес - правила из репозитория, брокер распределяет данные по адресатам.
Среди методов адресации, основанной на содержании информации, особое место занимает модель публикация-подписка. Интеграционный брокер принимает заявки о подписке на информацию по темам от приложений-подписчиков и тематические сообщения-публикации от приложений-публикаторов. Распределение публикаций по подписчикам на основании совпадения тематик является гибким динамическим механизмом маршрутизации информации.
Взаимодействие потока сообщений с базами данных. Системы управления базами данных являются наиболее общим элементом современных вычислительных систем. Обмен информацией между сообщениями и базой данных, между внешней динамической транспортной системой и внутренней средой прикладных систем, является общим действием. Подобный обмен должен быть реализован посредством наиболее естественных языковых и интерфейсных инструментов для обеих сред, то есть должен поддерживать стандарты SQL, ODBC, XML.
Серверы баз данных имеют специальные средства для сбора, передачи и загрузки данных. Для задач синхронизации используются механизмы репликации данных. В отличие от интеграционных брокеров подобный класс средств ориентирован на работу только с базами данных. Если сравнивать возможности интеграционного брокера и упомянутых средств сервера баз данных, то становится очевидным, что, имея ограниченные возможности для поддержания целостности баз данных, брокеры сообщений предоставляют гораздо более надежные транспортные механизмы, гибкую маршрутизацию и, наконец, возможности для интеграции в режиме реального времени.
Средства разработки брокера. Брокер сочетает в себе черты среды разработки и исполнения. Простота и удобство проектирования процедур обработки передаваемых данных важны для эффективности использования брокера. Средства проектирования процедур обработки должны быть просты и наглядны в освоении и применении, предоставлять возможности для групповой работы, поддерживать открытость процедур для повторного использования и изменения кода.
Принципы построения WebSphere Message Broker
Брокер сообщений соединяет в себе средства разработки, масштабируемую среду исполнения и средства моделирования.Основные компоненты WebSphere Message Broker - это система исполнительных брокеров, сервер конфигурации (Configuration Manager), универсальная графическая среда разработки и администрирования Message Broker Toolkit.
Взаимодействие между компонентами WebSphere Message Broker базируется на очередях WebSphere MQ. Все команды и запросы, идущие от Message Broker Toolkit на сервер конфигурации реализуются в виде сообщений. Сам сервер конфигурации и брокеры связаны при помощи очередей сообщений WebSphere MQ, через которые передаются внутренние управляющие и отчетные сообщения WebSphere Message Broker в формате XML. Для постоянного хранения конфигурационной информации, данных о форматах, потоках обработки сервер конфигурации и брокеры используют реляционные базы данных. Стандартно в WebSphere Message Broker входит СУБД DB2, однако для работы брокера можно использовать другие СУБД: Oracle, MS SQL Server, Sybase. Сервер конфигурации является центральным компонентом, управляющей ведением репозитория форматов и бизнес-правил, работой брокеров.
Брокеры отвечают за исполнение потоков обработки, то есть являются исполнительной средой. Каждый брокер имеет собственную базу данных, хранящую часть данных главного репозитория. Многопроцессовая и многопоточная архитектура брокера обеспечивает масштабируемость системы при интенсивных потоках сообщений.
Поток обработки сообщения и его визуальное конструирование. Обработка сообщения, попавшего в брокер, определяется так называемым потоком или схемой обработки сообщения (message flow). Поток обработки состоит из последовательности операций над сообщением и конструируется при помощи набора существующих обработчиков (рис.12.4). Обработчики WebSphere Message Broker - это по сути процедуры, настраиваемые по параметрам. Они реализуют отдельный шаг или специализированную функцию процесса обработки. В свойствах обработчиков-процедур определяются параметры, необходимые для исполнения данного потока. Например, если обработчик читает сообщения из очереди WebSphere MQ, то в качестве параметра указывается имя очереди. Если другой обработчик предназначен для обращения к внешней базе данных, то среди его параметров будут названия базы, таблиц и полей. Поток обработки визуально набирается из необходимых обработчиков, которые обладают точками входа и выхода - терминалами, входные и выходные терминалы обработчиков связываются соединениями, образуя направленный граф, реализующий пошаговую последовательность обработки сообщения.
Рис. 12.4. Компоненты потока обработки сообщений
Как правило, каждый поток обработки начинается с обработчика Input и заканчивается одним или несколькими обработчиками Output, используется транспорт WebSphere MQ и входная очередь для приема информации извне. Для других случаев можно заменить стандартный входной обработчик на собственный обработчик. Основное назначение обработчика Input, кроме того, чтобы прочитать пришедшее сообщение из очереди WebSphere MQ, правильно интерпретировать его тип и формат, а также разбить его на отдельные поля. При этом в зависимости от типа сообщения обработчик может подключать различные парсеры (программы разбора формата сообщения). Последний обработчик в потоке Output завершает процесс обработки сообщения в данном потоке и отправляет его по назначению в очередь или список очередей. Среди параметров обработчика Output, кроме адресной информации содержатся важнейшие определения уровня транзакционности данного потока обработки, постоянства создаваемого сообщения, передачи контекста и идентификационной информации из исходного сообщения во вновь создаваемое сообщение.
Существует группа обработчиков, которая предназначена для реализации проверок и управляющих конструкций внутри потока обработки, например, обработчик Filter разделяет поток обработки на ветви в зависимости от условия фильтрации. Условные переходы с динамическими и статическими назначениями внутри потока обеспечиваются обработчиками RouteToLabel и Label. Для реакции на возникающие ошибки и обработку исключительных состояний существуют обработчики TryCatch и Throw. Трассировка и проверка корректности потока и структуры проходящих сообщений осуществляются соответственно обработчиками Trace и Check. FlowOrder определяет порядок прохождения отдельных ветвей потока обработки.
Для взаимодействия с базами данных имеются специализированные обработчики Database, DatabaseInsert, DatabaseUpdate, DatabaseDelete позволяющие визуально назначать связи и преобразования между полями базы данных и полями сообщения (рис.12.5). Наиболее часто используемым и универсальным по возможностям является обработчик Compute, который позволяет писать разнообразные программы-скрипты на языке ESQL.
Рис. 12.5. Пример потока обработки сообщений
Домены сообщений. При обработке любого сообщения, попавшего в WebSphere Message Broker, прежде всего, выполняется процедура отнесения сообщения к правильному домену и разбиение сообщения на отдельные поля. Сообщения, которые способен обрабатывать WebSphere Message Broker, могут относиться к одному из нескольких основных доменов, а именно XML, JMS, MRM, NEON, BLOB. Некоторые типы сообщений WebSphere Message Broker может распознавать и обрабатывать динамически, то есть без предварительного занесения метаданных в репозиторий, например, так происходит обработка корректно определенных XML документов. Для других типов XML документов требуется занесение в репозиторий. Сообщения, относящиеся к домену MRM (Message Repository) являются сообщениями из внутреннего репозитория WebSphere Message Broker. Сообщения, созданные приложениями при помощи интерфейса JMS могут относиться к нескольким доменам: текст, потоки, карты и объекты Java. WebSphere Message Broker поддерживает их разбор и интерпретацию. Кроме этого, WebSphere Message Broker включает развитую технологию разбора и обработки сообщений, лицензированную IBM у фирмы NEON и обрабатывает сообщения из соответствующего домена. Наконец, сообщения неструктурированные или с неизвестной структурой относятся к домену BLOB. Для каждого из доменов используются собственные разборщики-парсеры.
Важным является вопрос о том, как WebSphere Message Broker определяет, к какому домену относится сообщение. Информация о домене сообщения и сопутствующих параметрах (идентификаторе набора, типе формата и т.д.) может быть определена двумя методами - либо содержаться в самом сообщении, либо быть определенной в Message Broker, в настройке входного обработчика INPUT конкретного потока обработки (рис.12.6). В первом случае для определения собственного содержимого сообщением используется специальное поле FORMAT стандартного заголовка сообщений WebSphere MQ. Кроме этого, приложение может вставить в сообщение специальный подзаголовок MQRFH2, имеющий поля для определения набора, типа и формата сообщения. Для случая настройки потока, у входного обработчика потока обработки Input есть соответствующие параметры, позволяющие задавать значения доменов, форматов и типов для сообщений, которые будут попадать во входную очередь.
Рис. 12.6. Внутреннее представление сообщений WebSphere Message Broker
Средства программирования и администрирования брокера сообщений
Разработчики WebSphere Message Broker создали в составе своего продукта язык ESQL, который как и все языки скриптов имеет очевидные преимущества: простота и удобство. В языке ESQL получил развитие широко используемый процедурный SQL, который был дополнен языковыми средствами для манипулирования с сообщениями разнообразных форматов. Краткое описание функциональных возможностей и основ программирования на ESQL заняло бы десяток страниц, поэтому здесь следует ограничиться некоторыми примерами кода на этом языке. Простое и наиболее часто встречающееся выражение ESQL:SET OutputRoot = InputRoot;
означает, что входящее сообщение на данном обработчике полностью копируется в выходное сообщение.
Следующий пример показывают применение встроенных функций - строковой функции SUBSTRING, функции преобразования типа CAST, временных функций INTERVAL, DATE:
SET "OutputRoot"."MRM"."RATES" = SUBSTRING( "InputBody"."ratedate" FROM 1 FOR 9); SET OutputRoot.XML."Days" = CAST( EXTRACT (DAY FROM INTERVAL ( CURRENT_DATE-DATE'2000-01-01')) AS CHAR);
Очередной пример иллюстрирует случай, когда информация о формате сообщения содержится в закодированном виде в прикладной части самого сообщения, случай типичный для закрытых или унаследованных систем. В приведенном примере информация о формате содержится в неявном виде в первых двух байтах сообщения. Вначале считая, что тело пришедшего сообщения бинарный объект BLOB, выделяется и проверяется значение первых двух байтов и переопределяется закодированный формат. После определения формата происходит переопределение типа сообщения в свойствах OutputRoot.Properties:
DECLARE TermId BLOB; SET TermId = SUBSTRING("InputBody"."BLOB" FROM 1 FOR 2); IF TermId = X'3031' THEN SET OutputRoot.Properties.MessageSet = 'ABC1234567890'; SET OutputRoot.Properties.MessageType = 'm_PERSON'; END IF;
Последний пример показывает одновременное использование операций с сообщением и обычного SQL, а именно ввод данных из сообщения во внешнюю реляционную базу данных, при этом для определения заранее неизвестного количества повторяющихся элементов в сообщении используется функции CARDINALITY:
DECLARE C1 INTEGER; SET C1 = CARDINALITY( Root.XML."BOOK"."CHAPTER"[]); DECLARE I INTEGER; SET I = 1; WHILE I <=C1 DO INSERT INTO Database.BOOK(TITLES) VALUES ( Root.XML."BOOK"."CHAPTER"[I]."TITLE"); SET I=I+1; END WHILE;
Администрирование брокера сообщений. Функционирование брокера сообщений требует инструментальных средств, которые должны поддерживать полный цикл жизнедеятельности брокера, начиная со средств разработки новых форматов и процедур обработки, включая инструменты тестирования и отладки, и кончая механизмами администрирования и мониторинга работы брокера и диагностики проблем. В WebSphere Message Broker используется единая интегрированная среда WebSphere Message Broker Toolkit, которая является универсальным инструментарием и для разработчика и для администратора.
Message Broker Toolkit построен на базе открытой технологии Eclipse и имеет ряд представлений, объединенных в единую графическую оболочку. Представление разработчика Broker Application Development позволяет работать с внутренним репозиторием форматов MRM. Форматы для наборов сообщений могут определяться путем визуального конструирования, как методом последовательной детализации сложных форматов сверху вниз, так и составлением новых форматов из уже существующих более простых форматов и элементов. Форматы могут быть импортированы и экспортированы, в частности из таких источников как заголовочные файлы языка С или СОBOL, файлы экспортированных метаданных MQ Integrator, схемы и DTD файлы для XML документов и т.д.
Графический построитель потоков обработки (Message flows) - основное средство разработки прикладной логики брокера. Именно при помощи этой составляющей разработчики конструируют схемы обработки сообщений из обработчиков. Важной функцией является переключение из режима конструирования потока в режим тестирования потока сообщений. Расставив контрольные точки в различных местах потока обработки, разработчики имеют возможность получать в этих точках полную развернутую информацию о структуре проходящих сообщений с прикладными и служебными атрибутами. Тестирование позволяет детально отслеживать процесс обработки сообщений в брокере и получить информацию о проблемах.
Используя представление администратора Broker Administration, пользователь может назначать разработанные потоки обработки брокерам на исполнение, возвращать потоки обратно в состояние разработки и динамически распространять сделанные программистами изменения на уже работающие потоки. Через это представления администратор определяет общую топологию среды распределенных брокеров WebSphere Message Broker, которые могут физически функционировать на различных операционных системах, в частности WindowsNT/2000/XP, Linux, UNIX, OS/390(z/OS), а логически могут образовывать иерархически построенные коллективы брокеров. Представление отображает состояние действующих брокеров и потоков обработки. Администратор WebSphere Message Broker может активизировать или приостановить работу отдельного потока, а также выполнять трассировку потоков разработки. Наконец, в журнале брокера отражаются успешные или неуспешные административные операции WebSphere Message Broker. В отношении использования Message Broker Toolkit остается упомянуть о возможностях групповой разработки, персональных настройках среды и разграничении функций в соответствии с ролями.
Проблема производительности и внутренняя архитектура. При всех своих достоинствах и богатой функциональности интеграционный брокер имеет и недостатки. В частности, поскольку брокер представляет собой единую фокусную точку для взаимодействия многих приложений, возрастает вероятность появления ошибок и сбоев именно в этой точке. Соответственно повышаются требования по надежности, производительности и масштабируемости внутренней архитектуры самого брокера.
Внутренняя работа каждого брокера Message Broker управляется специальным процессом-контролером. За взаимодействие с сервером конфигурации и ведение внутренних данных брокера и кэш-таблиц отвечает особый процесс - агент брокера.
Для непосредственной обработки сообщений существуют процессы - исполнительные группы. На этапе конфигурирования системы каждый поток обработки назначается исполнительной группе. Внутри каждой исполнительной группы может быть задействовано до 256 отдельных подпроцессов - трэдов (thread). При появлении нового сообщения во входной очереди потока обработки, для исполнения потока назначается свободный трэд исполнительной группы, а следующий свободный трэд начинает наблюдать за входной очередью в режиме ожидания. Новые сообщения в очереди активизируют новые экземпляры потока обработки.
Расширение функциональности: обработчики и парсеры. WebSphere Message Broker позволяет расширять свою функциональность путем создания новых обработчиков для программирования типичных функций и встраивать собственные разборщики-парсеры для разбора специализированных форматов сообщений. Среди уже существующих дополнительных обработчиков, которые можно свободно взять с сайта поддержки Support packs следует отметить: Sendmail - для посылки электронной почты; LDAP, FTPSend - посылки файла по FTP; MQGet, ExecuteTime, CICS Client, XSLT, EJB; парсеры - для сообщений со спецификацией HL7 для учреждений здравоохранения; для документов SAP IDOC прикладного пакета R/3 фирмы SAP; для сообщений спецификации ACORD AL3 из страховой индустрии; для сообщений спецификации финансовой информации FIX.
Взаимодействие с системами управления бизнес-процессами. Системы управления бизнес - процессами или workflow systems предоставляют возможности моделировать сложные деловые процессы на предприятиях и затем обеспечивать их исполнение и мониторинг, включая автоматические функции распределения назначений, ответственности и данных между людьми и прикладными системами в соответствии с моделью делового процесса.
Системы управления бизнес - процессами дают возможность отделять среду моделирования, управления и контроля исполнения деловых процессов от внутренней закодированной логики прикладных систем, что позволяет гибко изменять деловые процессы в соответствии с развитием бизнеса.
Системы управления бизнес-процессами и брокеры сообщений взаимно дополняют друг друга, соединяя функции управления бизнес-процессами с функциями трансформации и распределения данных. Например, если для какого-либо бизнес-процесса системы управления, необходимо сделать запрос к какой-либо внешней системе или выполнить внешнюю функцию, то подобный внешний вызов в системе управления бизнес-процессами WebSphere MQ Workflow реализуется в виде XML сообщения. Затем оно может быть получено и преобразовано брокером сообщений в сообщение формата внешней системы или обработано на самом брокере. Результат выполнения будет возвращен в систему управления бизнес-процессами WebSphere MQWorkflow и воспринят, как окончание очередной стадии бизнес процесса. В другом случае, сообщение от внешней системы прошедшее через брокер, может вызвать старт бизнес-процесса под контролем системы управления WebSphere MQ Workflow. При этом система управления бизнес-процессами может реализовать в интересах брокера сложную логику разбора и обработки сообщения.
Количество интеграционных задач в вычислительной среде современного предприятия стремительно растет и потребность в интеграционном программном обеспечении очевидна. Системы очередей сообщений являются сегодня фундаментом интеграционных программных технологий. На базе очередей сообщений вместе с компонентами промежуточной обработки, такими как интеграционные брокеры, адаптеры, обработчики и технологии открытых интерфейсов WebServices возникает новый стратегический класс программного обеспечения - корпоративная сервисная шина (Enterprise Services Bus - ESB), который должен стать базовым слоем современной вычислительной корпоративной архитектуры.
DECLARE C1 INTEGER; SET C1 = CARDINALITY( Root.XML."BOOK"."CHAPTER"[]); DECLARE I INTEGER; SET I = 1; WHILE I <=C1 DO INSERT INTO Database.BOOK(TITLES) VALUES ( Root.XML."BOOK"."CHAPTER"[I]."TITLE"); SET I=I+1; END WHILE;
Администрирование брокера сообщений. Функционирование брокера сообщений требует инструментальных средств, которые должны поддерживать полный цикл жизнедеятельности брокера, начиная со средств разработки новых форматов и процедур обработки, включая инструменты тестирования и отладки, и кончая механизмами администрирования и мониторинга работы брокера и диагностики проблем. В WebSphere Message Broker используется единая интегрированная среда WebSphere Message Broker Toolkit, которая является универсальным инструментарием и для разработчика и для администратора.
Message Broker Toolkit построен на базе открытой технологии Eclipse и имеет ряд представлений, объединенных в единую графическую оболочку. Представление разработчика Broker Application Development позволяет работать с внутренним репозиторием форматов MRM. Форматы для наборов сообщений могут определяться путем визуального конструирования, как методом последовательной детализации сложных форматов сверху вниз, так и составлением новых форматов из уже существующих более простых форматов и элементов. Форматы могут быть импортированы и экспортированы, в частности из таких источников как заголовочные файлы языка С или СОBOL, файлы экспортированных метаданных MQ Integrator, схемы и DTD файлы для XML документов и т.д.
Графический построитель потоков обработки (Message flows) - основное средство разработки прикладной логики брокера. Именно при помощи этой составляющей разработчики конструируют схемы обработки сообщений из обработчиков. Важной функцией является переключение из режима конструирования потока в режим тестирования потока сообщений. Расставив контрольные точки в различных местах потока обработки, разработчики имеют возможность получать в этих точках полную развернутую информацию о структуре проходящих сообщений с прикладными и служебными атрибутами. Тестирование позволяет детально отслеживать процесс обработки сообщений в брокере и получить информацию о проблемах.
Интеграция приложений на основе WebSphere MQ
Криптографическая методология MQSecure
Появление продукта MQSecureTM обусловлено отсутствием механизмов SSL в более ранних чем 5.3 версиях WebSphere MQ и необходимостью более глубокого уровня шифрования (уровня приложений) и, кроме этого, усилением защиты на уровне связей. Ведь после SSL "рукопожатия" возможна подмена идентификатора пользователя без указания пароля и проблема безопасности опять становится актуальной. Кроме этого, удаленное администрирование дает злоумышленнику возможность остановки каналов и просмотра сообщений в очереди, снятие SSL защиты и т.п.Основу MQSecure составляет криптографическая методология RSA, включающая крупноразмерные открытый/секретный ключи, цифровую подпись сообщений для обеспечения неизменности, аутентификации и подлинности сообщений. Распространение открытых ключей использует концепцию цифровых сертификатов, в которой ключи посылаются только истинным аутентифицированным источникам. Для шифрования используются различные алгоритмы, начиная от AES (наиболее сильный), далее RC6, RC5, RC4, TDES и заканчивая RC2 (наиболее слабый). Даже самые сильные алгоритмы шифрования не понижают производительность WebSphere MQ (скорость потока сообщений) более чем на 10%.
Для защиты на уровне связей используются Channel - Exit программы, как и в SSL. При этом аутентификация пользователя осуществляется для каждого сообщения. Для защиты на уровне приложений используются специальные макрокоманды для WebSphere MQ, поставляемые вместе с MQSecure:
MQSecure поддерживает различные полезные опции для разработчиков: прямые и непрямые WebSphere MQ обращения, машинный уровень аутентификации, аутентификацию пользователей, доступ к групповой/ролевой аутентификации. Таким образом, MQSecure обеспечивает сквозную безопасность.
Безопасность на уровне связей предполагает цифровую подпись и шифрование каждого сообщения. Если сообщение на принимающей стороне воспринимается как недействительное, то оно попадает в очередь недоставленных сообщений (Dead letter queue) или в специальную очередь недействительных сообщений MQSecure, где оно хранится в первозданном зашифрованном виде для анализа, а не в модифицированном виде для Dead letter queue. Если сообщение воспринимается как законное и действительное, то оно помещается в очередь назначения в первозданном виде для дальнейшей обработки приложением. Во время нахождения сообщения в очереди существует возможность при наличии внутренних администраторов-злоумышленников корпоративной сети "перехватить" сообщение. Вот почему безопасность на уровне приложений дает большую защищенность, так как сообщение на всем пути следования
База данных - источник => WebSphere MQ => База данных - приемник
обеспечено криптографической защитой. Кроме того, сообщение нельзя посмотреть в очереди отправления или в очереди приема - там оно уже зашифровано! Защиту на уровне приложений целесообразно закладывать на этапе проектирования приложений. Модифицировать работающие программы, как известно, занятие малоприятное.
Методика работы WebSphere MQ с SSL
SSL (Secure Sockets Layer - "слой защищенных сокетов") был первоначально создан компанией Netscape, чтобы обеспечить поверх обычного протокола HTTP дополнительный защищенный "слой". Этот дополнительный слой позволяет идентифицировать стороны на основе сертификатов, осуществлять шифрование передаваемых данных и подтверждать то, что информация в процессе передачи не искажалась. В настоящее время SSL стал стандартом защиты данных, передаваемых по сетям общего пользования. SSL протокол применяет две различные схемы шифрования: асимметричную и симметричную.Принцип работы SSL. При инициализации сеанса связи (процесс "SSL - рукопожатие" - "SSL handshake") стороны используют асимметричную схему шифрования. В этот период стороны идентифицируют друг друга по сертификату и договариваются об алгоритме и ключе шифрования, которые будут использоваться при симметричной схеме. По завершению процесса "SSL - рукопожатия" на каждой стороне имеется разовый секретный ключ (secret key), которым шифруется весь последующий трафик. Кроме этого, используя механизм электронной подписи, SSL гарантирует неизменность данных в процессе их передачи.
Более подробно описание работы с SSL можно разобрать на примере настройки WebSphere MQ SSL для двух менеджеров: QM1 (порт 1515) и QM2 (порт 1616) и двух каналов: QM2.QM1 и QM1.QM2, которые используют опцию настройки TRIPLE_DES_SHA_US.
Когда стартует канал-отправитель QM2.QM1, начинается "SSL рукопожатие":
Из приведенного диалога следует, что WebSphere MQ сервер QM1 должен иметь сертификат и сервер QM2 должен уметь расшифровывать подписанный сертификат.
Вариантов получения сертификата для сервера QM1 может быть несколько:
В тестовых целях можно получить бесплатно демонстрационный персональный сертификат из GlobalSign.com, действительный 30 дней. Есть и другие сайты для этих целей, но GlobalSign не требует регистрации. Сертификат для других, не демонстрационных целей, конечно, не будет бесплатным.
Далее методику настройки WebSphere MQ с SSL можно изложить в виде следующих шагов-рекомендаций для работы в операционной системе Windows.
Основы обеспечения безопасности WebSphere MQ
Любой специалист, системный администратор, системный интегратор и руководитель ИТ подразделения должен отдавать себе отчет в том, что WebSphere MQ - незащищенная система и потоки сообщений в ней легко читаются, если не предпринять специальных мер защиты. Администратор на собственном компьютере и член группы mqm имеет доступ со своим паролем ко всем удаленным менеджерам корпоративной сети, а также возможность чтения и записи сообщений в любую очередь. Например, к менеджеру очередей на UNIX-платформе можно подключится как пользователь с именем root и собственным паролем. Важнейшее преимущество WebSphere MQ - многоплатформенность - далось ценой недостаточной защищенности. Вместе с тем, к безопасности системы WebSphere MQ можно сформулировать ряд требований.Для обеспечения безопасности WebSphere MQ, начиная с версии 5.3, IBM поставляется встроенный механизм SSL (Secure Sockets Layer). Кроме этого у IBM существует специализированный продукт для этих целей - MQSecure, разработанный еще в компании Candle до ее присоединения к IBM и работающий на всех платформах. В России появился свой продукт для этих целей: MQКрипто компании " ФакторТС", работающий под Windows с алгоритмом ГОСТ 28147-89 и ключом 256 бит.
Работа всех этих средств защиты основана на следующей концепции безопасности. Для обеспечения безопасности WebSphere MQ должны решаться задачи: идентификации и аутентификации. Идентификация означает распознавание уникального пользователя в операционной системе или в приложении, которое работает в системе. Аутентификация означает проверку того, что пользователь является именно той персоной, которой он заявляет себя в системе или приложении. Например, при входе в систему пользователь вводит идентификатор (user ID) и пароль (password). Система использует user ID для идентификации и пароль для аутентификации. Для WebSphere MQ можно привести подобные примеры идентификации и аутентификации.
Для обеспечения безопасности WebSphere MQ предлагается 2 уровня: безопасность на уровне связей и на уровне приложений. Безопасность на уровне связей обеспечивается непосредственно MCA, как показано на рис.13.1.
При этом канальные агенты на каждом конце осуществляют аутентификацию партнера, шифрование и расшифровывание сообщений, проверку того, что сообщение доставлено по назначению. В WebSphere MQ 5.3 этот уровень реализован на основе SSL и рассмотрен ниже.
Безопасность на уровне приложений реализуется при помощи MQI обращений в приложениях, и при этом могут использоваться и другие продукты, которые поддерживают WebSphere MQ, например, MQSecure. Этот уровень безопасности называют иногда безопасность на уровне сообщений или сквозная безопасность (end-to-end security). Сквозная безопасность позволяет защитить сообщения, когда они поступают в очереди на другой менеджер и этот уровень безопасности несомненно выше, чем безопасность на уровне связей, хотя и требует дополнительных затрат на этапе разработки приложений.
Основная криптографическая терминология [23], [24], [25]. Криптографические методы защиты делятся на два класса алгоритмов: симметричный алгоритм (или алгоритм с симметричным ключом) и асимметричный алгоритм (или алгоритм с открытым ключом), проиллюстрированные на рис.13.2. Открытым ключом (public key) называют ключ для шифрования информации. Закрытым или секретным ключом (secret key) называют ключ для расшифровывания данных.
Рис. 13.1. Обеспечение безопасности WebSphere MQ на уровне связей
В алгоритмах с симметричными ключами (symmetric key) отправитель и получатель используют один и тот же, общий ключ, как для шифрования информации, так и для ее расшифровывания. Преимущества алгоритмов с симметричными ключами:
Недостатки алгоритмов с симметричными ключами:
Для обеспечения безопасности WebSphere MQ, начиная с версии 5.3, IBM поставляется встроенный механизм SSL (Secure Sockets Layer). Кроме этого у IBM существует специализированный продукт для этих целей - MQSecure, разработанный еще в компании Candle до ее присоединения к IBM и работающий на всех платформах. В России появился свой продукт для этих целей: MQКрипто компании " ФакторТС", работающий под Windows с алгоритмом ГОСТ 28147-89 и ключом 256 бит.
Работа всех этих средств защиты основана на следующей концепции безопасности. Для обеспечения безопасности WebSphere MQ должны решаться задачи: идентификации и аутентификации. Идентификация означает распознавание уникального пользователя в операционной системе или в приложении, которое работает в системе. Аутентификация означает проверку того, что пользователь является именно той персоной, которой он заявляет себя в системе или приложении. Например, при входе в систему пользователь вводит идентификатор (user ID) и пароль (password). Система использует user ID для идентификации и пароль для аутентификации. Для WebSphere MQ можно привести подобные примеры идентификации и аутентификации.
Для обеспечения безопасности WebSphere MQ предлагается 2 уровня: безопасность на уровне связей и на уровне приложений. Безопасность на уровне связей обеспечивается непосредственно MCA, как показано на рис.13.1.
При этом канальные агенты на каждом конце осуществляют аутентификацию партнера, шифрование и расшифровывание сообщений, проверку того, что сообщение доставлено по назначению. В WebSphere MQ 5.3 этот уровень реализован на основе SSL и рассмотрен ниже.
Работа с WebSphere MQ через Интернет/Интранет
Работа с WebSphere MQ в Интранет возможна при помощи Internet Explorer почти так же, как и с WebSphere MQ Explorer. Читатель может легко настроить работу с WebSphere MQ в интранет через Internet Explorer на основе следующих простых правил:В корпоративных системах работа через Интернет, в отличие от интранет, требует обязательной защиты от внешних посягательств, например, такими средствами как шифрование данных через SSL, демилитаризованная зона (Demiliatarized Zone - DMZ), FireWall. Поэтому для работы с WebSphere MQ клиентом и такими средствами защиты понадобится установить с сайта ИБМ свободно распространяемый SupportPacs MS81 - WebSphere MQ internet pass-thru (MQIPT):
http://www-306.ibm.com/software/integration/support/supportpacs/category.html
MQIPT создан для подключения клиента WebSphere MQ версии 5.3 к WebSphere MQ менеджеру очередей с использованием SSL. MQIPT устанавливается на WebSphere MQ клиенте или в DMZ на WebSphere MQ сервере и работает как proxy-сервер для WebSphere MQ трафика. Типичный пример подключения MQIPT приведен на рис.13.12.
Рис. 13.12. Схема подключения MQIPT
Эта схема показывает, как MQIPT моделирует клиента и SSL-защищенный канал. В этой схеме может использоваться любой сертификат, заверенный центром сертификации (CA). MQIPT имеет свой простой сертификат, который может быть установлен на WebSphere MQ менеджере и MQIPT в целях тестирования.
Настройка такой конфигурации состоит из следующих шагов.
На машине с WebSphere MQ сервером создается менеджер с именем, например, QM. MQIPT инсталлируется на другой машине в директорию C:\mqipt вместе с WebSphere MQ клиентом. Стандартные команды для клиента и сервера (amqsputc, amqsgetc) работают. На WebSphere MQ сервере создаются: менеджер очередей MQIPT.QM1, канал server connection с именем MQIPT.CONN.CHANNEL, локальная очередь MQIPT.LOCAL.QUEUE, TCP/IP listener для MQIPT.QM1 на порту 1414.
Для этого необходимо импортировать сертификат в Windows Internet Explorer: выбрать в меню "Tools" => "Content" => "Certificates" и нажать кнопку "Import". Найти сертификат на пути c:\mqipt\ssl\sslSample.pfx и ввести пароль "mqiptV1.3" (без кавычек). Выбрать "Automatically select the certicate store based on the type of certificate" и нажать "Finish". Далее следует импортировать сертификат в WebSphere MQ Explorer. На свойствах MQIPT.QM1 выбрать закладку SSL, нажать the "manage SSL certificates" и "add" - добавить. Среди сертификатов выбрать только что добавленный сертификат, подписанный "Phil Blake", и нажать "add" - добавить. После этого для нашего сертификата нажать кнопку "assign" - назначить.
В свойствах канала MQIPT.CONN.CHANNEL выбрать закладку SSL, из выпадающего меню выбрать RC4_MD5_EXPORT и нажать кнопку "OK".
MQIPT должен быть сконфигурирован как SSL клиент. Для этого выбрать конфигурационный файл c:\mqipt\mqipt.conf и отредактировать его следующим образом для определения маршрута для SSL клиента:
[route] ListenerPort=1415 Destination=10.20.9.2 DestinationPort=1414 SSLClient=true SSLClientKeyRing=c:\\mqipt\\ssl\\sslSample.pfx SSLClientKeyRingPW=c:\\mqipt\\ssl\\sslSample.pwd SSLClientCipherSuite=SSL_RSA_EXPORT_WITH_RC4_40_MD5
Примечание. Соответствие CipherSpec и SSLClientCipherSuite определяется таблицей:
| DES_SHA_EXPORT | SSL_RSA_WITH_DES_CBC_SHA |
| DES_SHA_EXPORT1024 | SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA * |
| NULL_MD5 | SSL_RSA_WITH_NULL_MD5 |
| NULL_SHA | SSL_RSA_WITH_NULL_SHA |
| RC2_MD5_EXPORT | SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 |
| RC4_56_SHA_EXPORT1024 | SSL_RSA_EXPORT1024_WITH_RC4_56_SHA * |
| RC4_MD5_US | SSL_RSA_WITH_RC4_128_MD5 |
| RC4_MD5_EXPORT | SSL_RSA_EXPORT_WITH_RC4_40_MD5 |
| RC4_SHA_US | SSL_RSA_WITH_RC4_128_SHA |
| TRIPLE_DES_SHA_US | SSL_RSA_WITH_3DES_EDE_CBC_SHA |
После этого активизировать MQIPT через командное окно:
cd \mqipt\bin mqipt ..
В командном окне появятся консольные сообщения, сообщающие об успешном старте MQIPT.
Менеджер QM1 и MQIPT готовы для совместной работы. На клиенте переменная MQSERVER должна отражать IP - адрес вашего сервера и для этого установить в командном окне:
SET MQSERVER=TEST.CONN.CHANNEL/TCP/10.20.3.1
Теперь помещение сообщения в очередь можно сделать командой:
amqsputc MQIPT.LOCAL.QUEUE MQIPT.QM1
а извлечение сообщения из очереди делается командой:
amqsgetc MQIPT.LOCAL.QUEUE MQIPT.QM1
Конфигурирование выполнено успешно и WebSphere MQ клиент версии 5.3 может работать через SSL защиту с использованием MQIPT и Интернет.
Таким образом, MQIPT позволяет сформировать канал для создания SSL- соединения и работы через Интернет. Работа между менеджерами осуществляется также просто. MQIPT дает возможность осуществлять трассировку передачи сообщений по каналу связи.
В завершение раздела хочется отметить еще две полезные особенности WebSphere MQ: работа по выделенным каналам связи и работа через модем. По выделенным каналам, как только установится надежная TCP/IP связь, работа ничем не отличается от работы в локальной сети. Каналы стартуют как обычно, может быть на 1-2 секунды дольше, если речь идет о тысячах километров и оптоволоконных каналах связи. Сообщения движутся так же быстро, надежность доставки гарантируется. Главное, чтобы канал связи обеспечивал качественную связь, а WebSphere MQ доставит, например, котировки курсов акций со всего мира за считанные секунды.
При работе WebSphere MQ через модем необходимы, как правило, специальные программы, которые обеспечивают дозвон и устанавливают TCP/IP адресацию. После этого запускается приложение, работающее через WebSphere MQ клиента с удаленным WebSphere MQ сервером. Это наиболее типичный вариант работы, ведь, как известно, WebSphere MQ клиент IBM распространяет бесплатно через Интернет (в версии 5.3 WebSphere MQ клиент имеет объем 86Мбт и это не всегда удобно - прим. авторов). Таким образом, число клиентских приложений не ограничено по финансовым соображениям и один WebSphere MQ сервер под Windows выдерживает подключение 3 - 5 тысяч клиентов со временем обслуживания менее 1 сек. Чем этот способ лучше обычной передачи файлов через модем? WebSphere MQ гарантирует доставку, скорость, целостность передачи, средства защиты через SSL и, наконец, отлаженную технологию интеграции данных и приложений.
с портом для listener 1515
Создается менеджер QM1 с портом для listener 1515 и объектами:DEFINE QLOCAL ('FROM.QM2') DEFINE QLOCAL ('QM1') USAGE(XMITQ) DEFINE QLOCAL ('QM1.DLQ') DEFINE QREMOTE ('TO.QM1') XMITQ('QM1') RNAME('FROM.QM2') RQMNAME('QM1') DEFINE CHANNEL ('QM2.QM1') CHLTYPE(RCVR) DEFINE CHANNEL ('QM2.QM1') CHLTYPE(SDR) XMITQ('QM1') CONNAME('MQSERVER(1515)')
Создается менеджер QM2 с портом для listener 1516 и объектами:
DEFINE QLOCAL ('FROM.QM1') DEFINE QLOCAL ('QM2') USAGE(XMITQ) DEFINE QLOCAL ('QM2.DLQ') DEFINE QREMOTE ('TO.QM1') XMITQ('QM2') RNAME('FROM.QM2') RQMNAME('QM1') DEFINE CHANNEL ('QM1.QM2') CHLTYPE(RCVR) DEFINE CHANNEL ('QM2.QM1') CHLTYPE(SDR) XMITQ('QM2') CONNAME('MQSERVER(1515)')
выбрать из выпадающего меню Certificates
На сайте http://www.GlobalSign.com/ выбрать из выпадающего меню Certificates пункт Personal Certificates и затем выбрать PersonalSign Demo. Это даст экран восьми шаговой процедуре для получения сертификата (рис.13.3). Нажать на пункт "Переход на Шаг 1" и выполнить действия из таблицы ниже:| Шаг 1. Проверка Root Certificate. Необходимо инсталлировать GlobalSign's Root Certificate. | Этот шаг выполняется автоматически. Нажмите "Переход на Шаг 2". |
| Шаг 2. Отправка e-mail адреса. Вышлите e-mail адрес и запомните введенный пароль. | У вас будет запрошен e-mail адрес и пароль, который понадобится на Шаге 4. После того как вы нажмете "Перейти на Шаг 3" GlobalSign вышлет вам сообщение по e-mail. |
| Шаг 3. Проверка почтового ящика. Вы получите письмо по e-mail от GlobalSign в ваш почтовый ящик и в нем будет ссылка. | Вы получите письмо по e-mail от "ca@GlobalSign.net" в течение 1 минуты. Письмо содержит ссылку. Нажмите на нее. |
| Шаг 4. Ввод пароля | Введите пароль, данный на Шаге 2 и нажмите "Переход на Шаг 5". |
| Шаг 5. Проверка ваших персональных данных | Вы можете кликнуть "Переход на Шаг 6" без каких-либо изменений. |
| Шаг 6. Подтверждение согласия с лицензионным договором | Нажмите "Согласен (Agree) для перехода на Шаг 7" |
| Шаг 7. Проверка почтового ящика. | Вы получите еще одно письмо по e-mail в течение 5 минут. Оно содержит ссылку, через которую открывается страница для загрузки вашего сертификата с кнопкой "Install" - инсталлировать (вы должны использовать тот же самый браузер, что и раньше) |
| Шаг 8. Инсталляция сертификата | Нажмите "Инсталлировать". Вы должны получить уведомление что ваш сертификат инсталлирован. Нажмите OK. |
увеличить изображение
Рис. 13.3. Процедура получения сертификата
Проверка инсталляции сертификата
После того как был инсталлирован сертификат, можно удостовериться, что это сертификат от GlobalSign. В Microsoft Internet Explorer необходимо перейти в пункт меню "Tools", выбрать "Internet options", нажать на закладку "Content" и еще раз нажать на "Certificates". После этого, откроется менеджер сертификатов и можно будет увидеть GlobalSign сертификат, предназначенный для e-mail адреса, заданного на шаге 2 (рис.13.4).Обычно необходимо только добавить сертификат
Обычно необходимо только добавить сертификат в хранилище сертификатов WebSphere MQ. Но из-за ошибки в версии 5.3, зафиксированной и исправленной в CSD1, следует использовать командную строку для добавления первого сертификата в WebSphere MQ.В интерфейсе командной строки нужно ввести следующие команды (этот шаг выполняется в графическом режиме, если установлен CSD1):
Первая команда дает список сертификатов из хранилища сертификатов операционной системы для текущего пользователя (MY). Вторая команда добавляет сертификат в хранилище сертификатов менеджера очередей. Копия экрана выполнения этих команд представлена на рис.13.5.
увеличить изображение
Рис. 13.4. Проверка инсталляции сертификата
увеличить изображение
Рис. 13.5. Добавление сертификата в хранилище сертификатов
в хранилище менеджера очередей. Необходимо
Можно увидеть множество сертификатов в хранилище менеджера очередей. Необходимо назначить менеджеру только что введенный сертификат, чтобы использовать его во время "SSL рукопожатия". Последовательность действий следующая.
увеличить изображение
Рис. 13.6. Назначение сертификата менеджеру очередей
увеличить изображение
Рис. 13.7. Проверка помеченной иконки сертификата
Когда QM1 посылает зашифрованный сертификат QM2, QM2 необходима авторизация сертификата для аутентификации QM1. Это делается на следующем шаге.
Перед тем как добавить сертификат
Перед тем как добавить сертификат в QM2, необходимо знать какой сертификат добавляется.Для этого следует:
GlobalSign Root CA
GlobalSign Primary Class 1 CA
GlobalSign PersonalSign Class 1 CA
Теперь необходимо добавить эти три сертификата в QM2. Для этого нужно сделать:
увеличить изображение
Рис. 13.8. Добавление ROOT сертификата в хранилище сертификатов QM2
увеличить изображение
Рис. 13.9. Добавление двух сертификата в хранилище сертификатов QM2
для получения SSL сертификата
увеличить изображение
Рис. 13.10. Выбор сертификата для QM2
Настройка SSL - свойств для каналов WebSphere MQ
увеличить изображение
Рис. 13.11. Выбор алгоритма шифрования в канале
Тестирование
Для тестирования можно остановить каналы, убрать в одном из них настройку SSL (CipherSpec установить в none) и попробовать стартовать каналы. Успешного старта отправляющего канала не произойдет, и он будет оставаться в состоянии retry. Вернув настройку SSL в канале в прежнее состояние, каналы можно успешно стартовать. После старта каналов следует передать сообщение, например, на менеджере QM1 командой:amqsput TO.QM2 QM1
Если сообщение передано успешно, то тест настройки SSL соединения следует считать выполненным успешно.
Для проверки шифрования в канале после отправки сообщения нужна специальная программа-перехватчик сообщений. Ведь в очередях на отправку и прием сообщения хранятся в незашифрованном виде. Такая программа может быть написана на C++ или Java как channel-exit программа для перехвата сообщений по порту 1515 для QM1 и по порту 1516 для QM2. В перехваченных сообщениях будет видно, что они зашифрованы. Написание такой программы читателю предлагается проделать самостоятельно или придумать другой способ проверки шифрования сообщений с помощью SSL-защиты на каналах менеджеров.
Заключительные замечания.
Интеграция приложений на основе WebSphere MQ
Настройка Omegamon для WebSphere MQ
При установке WebSphere MQ Monitoring Agent осуществляется настройка конфигурационного файла mq.cfg, пример структуры которого приведен ниже.SET GROUP NAME (GROUP1) - DEFAULT(YES) - COMMAND (YES) - MSGACCESS(DELETE) - EVENTS(REMOVE) SET MANAGER NAME(QM1) SET AGENT NAME(SERVER_MAIN) SET QUEUE NAME(*) MGRNAME(QM1) SET CHANNEL NAME(*) MGRNAME(QM1) PERFORM STARTMON SAMPINT(300) HISTORY(YES)
В этом файле задаются опции для мониторинга. Обязательным параметром при задании опций является имя менеджера MANAGER NAME, в данном случае QM1. Другими важными и полезными опциями являются:
Если возникла необходимость поменять опции, то после их изменения следует перестартовать агента для мониторинга. Опции для мониторинга подробно изложены в [27].
После установки агентов можно через CNP consol настраивать мониторинг и наблюдать все сервера с установленными агентами. Основным этапом настройки агентов Omegamon для работы с WebSphere MQ является создание ситуаций (situation). Omegamon позволяет за считанные минуты ввести и отладить правила мониторинга внештатных ситуаций для объектов КИС. Правило (situation) записывается как знания специалистов в виде так называемых продукций или, иначе говоря, условий ЕСЛИ …. ТО …...
На рис.14.2, рис.14.3 приведен вид интерфейса для создания ситуаций и показана ситуация, определяющая критическое количество сообщений в очередях WebSphere MQ.
увеличить изображение
Рис. 14.2. Интерфейс Omegamon для представления ситуаций (часть 1).
увеличить изображение
Рис. 14.3. Интерфейс Omegamon для представления ситуаций (часть 2).
Кроме мониторинга очередей наиболее типичными ситуациями для мониторинга объектов WebSphere MQ являются: мониторинг состояния каналов (останов, binding, retrying), мониторинг состояния менеджера очередей, мониторинг канала на предмет записи значений message count (только одно условие channel name = <имя канала>).
Дополнительным вариантом настройки агентов Omegamon для работы с WebSphere MQ может быть создание политики (Policy), которая служит для выполнения действий (ACTION) при срабатывании нескольких ситуаций одновременно, например, при мониторинге ситуаций на разных серверах, при подключении разных ситуаций в разное время и т.д.. Создание Policy осуществляется в CNP client (меню Edit => Workflow Editor) в графическом режиме. На рис.14.4 показан пример создания Policy для случая, когда требуется в NT кластере определить, что оба менеджера очередей остановлены, выдать предупреждение командой net send и попытаться запустить один из менеджеров командой strmqm.
увеличить изображение
Рис. 14.4. Пример создания Policy
В 90-х годах весьма популярны были экспертные системы (ЭС), под которыми понимаются программы, использующие знания специалистов (экспертов) о некоторой конкретной узко специализированной предметной области и которая в пределах этой области способна принимать решения на уровне эксперта-профессионала [28]. Исходя из этого определения можно сказать, что Omegamon – яркий представитель современных экспертных мультиагентных динамических систем, работающих в реальном времени. Логический вывод в такой ЭС реализован при помощи механизма policy, обеспечивающего построение цепочек логического вывода на основе situations.
Настройка рабочих областей и многопользовательской работы
Рассмотрим некоторые дополнительные особенности работы с Omegamon для WebSphere MQ и в первую очередь настройку рабочих областей (WorkSpace) для создания необходимых пользовательских окон (View) и отображения наиболее важной динамической информации за последние 1 – 2 часа. Как уже упоминалось, по умолчанию Omegamon имеет достаточно информативные настройки рабочих областей, но настройка пользовательских взглядов (custom workspace views) дает дополнительные удобства.Допустим желательно иметь окно с графиком прохождения сообщений через канал QM1_QM2.ch. Определим пользовательский взгляд с помощью следующих шагов.
Правой кнопкой мыши открываем свойства MyWorkSpace и нажимаем кнопку Click here to assign a querry и вызываем QuerryEditor.
Среди множества запросов (Querry) выбираем подходящий или создаем новый и модифицируем его, например,
Begin (Channel Name EQ ‘QM1_QM2.ch’ and Origin Name EQ $NODE$ and Message Count GT 0 ) End
Нажав кнопку OK, присваиваем созданный запрос нашему рабочему пространству MyWorkSpace.
Пользовательский взгляд готов и отображает динамику сообщений по каналу QM1_QM2.ch, например так, как показано на рисунке рис.14.5.
увеличить изображение
Рис. 14.5. Динамика сообщений по каналу QM1_QM2.ch
В меню View/Refresh Every можно выставить интервал съема значений: 30сек, 60сек, 5мин, 15мин, 60мин и по требованию. После этого можно наблюдать динамику прохождения сообщений. Можно установить всевозможные взгляды для отображения динамических изменений. В любой момент когда будет вызван экран CNP client эти взгляды покажут реальную динамическую картину о потоках в системе, например, как это показано на рис.14.6.
При работе нескольких администраторов с CNP важно чтобы каждый администратор видел только свои группы серверов для мониторинга, имел необходимые права и мог настроить необходимые окна для просмотра.
Рассмотрим методику настройки для некоторого администратора с именем mq_admin прав доступа через CNP-клиент к мониторингу подведомственных ему серверов CASH1, CASH2. Для этого в меню Edit Navigator View встаем на вершине дерева Enterprise, нажимаем кнопку Create Child Item, вводим Name, например, CASH_VIEW и переносим из окна Available Managed Systems в окно Assigned сервера для мониторинга, как показано на рис.14.7.
Далее в меню Edit вызываем окно Administer users и нажимаем кнопку Create New User и создаем пользователя cash_admin. Для этого пользователя в окне Navigator Views назначаем View = CASH_VIEW (рис.14.8). В разделе Permission этому пользователю предоставляем необходимые права. Как правило, это все права кроме User Administration, которые предоставляются главному Администратору Omegamon.
Теперь осталось проверить, чтобы в Candle Management Server в Configuration помечен флажок Security Validate User. При инсталляции этот флажок не помечен и вводиться default user = sysadmin без пароля. Пометив этот флажок и перегрузив CMS (stop and start Services), мы предоставляем пользователю mq_admin возможность загрузки клиентского окна CNP с login = mq_admin и с его сетевым паролем. И ни какому другому пользователю вход с именем mq_admin и соответствующие права не доступны в CNP Omegamon. Просто и эффективно. Более подробно эта методика описана в [29].
увеличить изображение
Рис. 14.6. Динамическая картина потоков в системе
увеличить изображение
Рис. 14.7. Создание взгляда Meridian (часть 1)
увеличить изображение
Рис. 14.8. Создание взгляда Meridian (часть 2)
Общая архитектура Omegamon
Для профессиональной работы с WebSphere MQ рекомендуется использовать средства мониторинга. Несмотря на высокую надежность WebSphere MQ сообщения могут застревать в очередях по разным причинам, прежде всего из-за нештатных ситуаций для программ обработчиков, пиковых перегрузок потоков данных, нестабильности работы корпоративной информационной сети (КИС). Рассмотрим систему Omegamon фирмы IBM (ранее Candle Corp., USA) для мониторинга WebSphere MQ. Согласно аналитическим отчетам группы Gartner компания Candle является бесспорным лидером среди компаний по обслуживанию инфраструктуры WebSphere MQ.Основными компонентами системы Omegamon, представленными на рис.14.1, являются:
Рис. 14.1. Структурная схема Omegamon.
Агенты Omegamon работают на контролируемых системах (Managed Systems) как первоклассные шпионы: они незаметны с точки зрения использования CPU и оперативны при мониторинге с точки зрения времени доставки своих донесений в центр. Они осуществляют контроль работы программного обеспечения (ПО) и имеют агентов для всех типов поддерживаемых операционных систем, сетевого программного обеспечения, баз данных (DB-2, ORACLE, SQL server и др.), WebSphere MQ, WebSphere Application Server, Enterprise Resource Planning (ERP) систем таких как SAP и др.ПО, для которого нет специализированных агентов и мониторинг осуществляется за счет универсального агента Universal Agent. Не работоспособность аппаратного обеспечения фиксируется автоматически как побочный результат неправильного функционирования программного обеспечения.
Агенты Omegamon фиксируют критическую ситуацию и обеспечивают реакцию (ACTION) менее чем за 1 секунду. Все определяется тем интервалом мониторинга, который задается экспертом на основе своих интуитивных знаний. В качестве ACTION при определении ситуаций можно использовать различные типы действий: посылка почтовых и sms-сообщений специалистам сопровождения, посылка информации в другие системы, выполнение системных команд и т.д. Количество объектов мониторинга (компьютеров КИС) может достигать несколько сотен и на каждом объекте может быть несколько сотен контролируемых параметров. Количество платформ (типов операционных систем), на которых работают агенты, превышает 30, начиная от OS/390,…,OS/400, далее различные UNIX платформы (HP_UX, AIX, Solaris …) и заканчивая Windows. На одном сервере может работать несколько агентов, например, для мониторинга WebSphere MQ (MQSeries), WebSphere Application Server, DB-2 и HP_UNIX одновременно. Именно эффективность агентов Omegamon, созданных профессионалами, позволила Candle стать лидером среди компаний по мониторингу WebSphere MQ и других программных продуктов.
Сервера CMS и CNP-servers могут работать на одном выделенном сервере, как правило, на базе операционной системы Windows. Настройка ситуаций (situations) и механизмов логического вывода (policy) производится на рабочем компьютере администратора через CNP-client. Для только что созданной ситуации вы нажимаете кнопку Apply и моментально видите отображение ACTION через CNP-client, через почту и т.д.
Работа с накоплением статистической информации
Как отмечалось ранее, пользовательские взгляды View или так называемые ShortStory предоставляют динамическую информацию за последние 1 – 2 часа. Omegamon предоставляет возможность накапливать статистическую информацию за месяцы и годы при помощи Warehouse Proxy агента и Microsoft SQL server на CMS. Этот механизм называют History Data Collection [30] или LongStory. Общая последовательность действий следующая.Накопление статистической информации через History Data Collection осуществляется с минимальным интервалом 5 минут. Это сделано специально, чтобы не переполнять базу данных SQL сервера. Иногда может понадобиться детальный анализ, например, с интервалом мониторинга 5 сек и записью значений в лог файлы. Это можно сделать с помощью ситуаций. Полученную информацию в дальнейшем можно будет использовать для анализа, построения графиков, презентаций и т.д.
увеличить изображение
Рис. 14.9. Настройка History Collection Configuration
увеличить изображение
Рис. 14.10. Графики на основе History Data Collection
Среди дополнительных особенностей Omegamon нельзя не отметить службу eDelivery, позволяющую в любой момент получить приобретенное и обновленное программное обеспечение Omegamon через Интернет. Это особенно важно в связи с появлением новых версий программного обеспечения и документации, приобретением новых агентов. На рис.14.11 показан интерфес для выбора и загрузки необходимого программного обеспечения Omegamon для WebSphere MQ через Интернет.
увеличить изображение
Рис. 14.11. Интерфейс для загрузки программного обеспечения через eDelivery
Важной особенностью системы Omegamon является возможность создания порталов для мониторинга. Суть создания порталов такова. Имеется несколько систем мониторинга в КИС, например, мониторинг сетевых ресурсов, мониторинг антивирусной защиты и мониторинг WebSphere MQ. Портал для мониторинга будет включать указанные системы мониторинга как подсистемы за счет получения информации через своего универсального агента (Universal Agent), установленного на системы мониторинга. Универсальному агенту через SNMP протокол передаются совокупности измеряемых параметров от каждой из систем мониторинга и портал для мониторинга будет работать по тем же принципам, что и описанная система Omegamon.
В заключение cледует подчеркнуть, что основанная на знаниях система мониторинга Omegamon это весьма эффективная система управления вычислительными ресурсами в целом и WebSphere MQ в частности, надежный и незаменимый помощник в поисках решений по оперативному устранению критических и трудных для диагностирования ситуаций, при анализе информационных потоков, анализе производительности и настройке КИС.
Бизнес в интернете: Сайты - Софт - Языки - Дизайн
- Киберсантинг
- Киберсантинг как бизнес
- Виды Киберсантинга
- Создание игр
- Дизайн как бизнес
- Dreamweaver
- PHP
- Homesite
- Frontpage
- Studio MX
- Сайтостроительство
- Citrix MetaFrame
- Стили сайта
- ActiveX на сайте
- HTML как основа сайта
- Adobe GoLive
- Что такое WEB
- Мобильные WAP сайты
- 3D графика на сайтах
- 3DS MAX графические решения
- Графика в 3D Studio MAX и на сайте