Архитектура и функции интеграционного решения

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

Криптографическая методология 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:

S_MQPUT (версия стандартного MQPUT для целей безопасности)S_MQGET (версия стандартного MQGET для целей безопасности)MQS_EXIT (MQ Channel - Exit программа)MQS_ADM (административный модуль)MQS_READ (фоновый модуль, который получает новый открытый ключ и помещает его в базу данных).

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 рукопожатие":

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

Из приведенного диалога следует, что WebSphere MQ сервер QM1 должен иметь сертификат и сервер QM2 должен уметь расшифровывать подписанный сертификат.

Вариантов получения сертификата для сервера QM1 может быть несколько:

можно создать самоподписанный сертификат (self-signed certificates).можно иметь собственный центр сертификации.можно потребовать сертификат из центра сертификации.

В тестовых целях можно получить бесплатно демонстрационный персональный сертификат из GlobalSign.com, действительный 30 дней. Есть и другие сайты для этих целей, но GlobalSign не требует регистрации. Сертификат для других, не демонстрационных целей, конечно, не будет бесплатным.

Далее методику настройки WebSphere MQ с SSL можно изложить в виде следующих шагов-рекомендаций для работы в операционной системе Windows.

Основы обеспечения безопасности WebSphere MQ

Любой специалист, системный администратор, системный интегратор и руководитель ИТ подразделения должен отдавать себе отчет в том, что WebSphere MQ - незащищенная система и потоки сообщений в ней легко читаются, если не предпринять специальных мер защиты. Администратор на собственном компьютере и член группы mqm имеет доступ со своим паролем ко всем удаленным менеджерам корпоративной сети, а также возможность чтения и записи сообщений в любую очередь. Например, к менеджеру очередей на UNIX-платформе можно подключится как пользователь с именем root и собственным паролем. Важнейшее преимущество WebSphere MQ - многоплатформенность - далось ценой недостаточной защищенности. Вместе с тем, к безопасности системы WebSphere MQ можно сформулировать ряд требований.

Отправка и прием сообщений WebSphere MQ должны осуществляться с проверкой подлинности пользователей (аутентификации) на основе паролей, ключей и т.п. Помещение сообщений в очередь на удаленном WebSphere MQ-менеджере не должно быть доступно "псевдоадминистратору" с собственного компьютера, подключившемуся к корпоративной транспортной системе WebSphere MQ. Нарушение этого требования ведет к риску подмены злоумышленником сообщений в транспортных потоках на ложные или фальсифицированные сообщения и финансовым потерям в крупных размерах.Система обеспечения безопасности WebSphere MQ должна иметь достаточно стойкие механизмы реализации процесса аутентификации, обеспечивать работу с сертификатами, ключами длиной до 256 бит и стойкими алгоритмами шифрования. Чтение сообщений в транспортных потоках WebSphere MQ, возможность перенаправить поток и организовать сбор информации на промежуточном компьютере не должны быть доступны "псевдоадминистратору" с собственного компьютера, подключившемуся с любым паролем к удаленному менеджеру очередей транспортной системы WebSphere MQ. Нарушение этого требования ведет к риску расшифровывания сообщений, утечки финансовой и конфиденциальной информации, финансовым потерям.Система обеспечения безопасности WebSphere MQ не должна понижать производительность работы транспортной системы более чем на 10%. Нарушение требования ведет к риску замедления работы КИС в целом.Система обеспечения безопасности WebSphere MQ должна работать стабильно (без собственных сбоев) 24 часа в сутки при достаточно больших потоках в сети (до 100000 сообщений в сутки). Нарушение требования ведет к риску нестабильности работы КИС.

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

Приложение, отправляющее сообщение, помещает в заголовок сообщения имя приложения и имя пользователя (user ID), связанного с этим приложением. Приложение, получающее сообщение, на основе этих данных производит идентификацию и аутентификацию (для надежной защиты WebSphere MQ этого недостаточно и можно легко подставить нужные данные, если знать о такой проверке).Во время старта канала, канальный агент (message channel agent - MCA) может проверять аутентификацию партнера. Это взаимная аутентификация предполагает, что посылающий и принимающий канальные агенты обмениваются сообщениями и проверяют друг друга на подлинность.

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

Производительность. Производительность алгоритмов с симметричными ключами достаточно велика.Стойкость. Алгоритмы с симметричными ключами очень стойкие, что делает практически невозможным процесс расшифровывания. При прочих равных условиях стойкость определяется длиной ключа. Длина ключа 40 или 56 бит (алгоритмы DES, MD5 компании RSA) обеспечивает защиту информационных потоков без финансовых рисков. При длине ключа 256 бит необходимо произвести 10 в 77 степени переборов для определения ключа.

Недостатки алгоритмов с симметричными ключами:

Распределение ключей. Для шифрования и расшифровывания применяется один и тот же ключ, и поэтому требуются надежные механизмы для распределения ключей.Масштабируемость. Единый ключ используется между отправителем и каждым получателем, и поэтому количество необходимых ключей возрастает в геометрической прогрессии. Для 10 пользователей нужно 45 ключей, а для 100 уже 499500.Ограниченное использование. Алгоритмы с симметричными ключами применяются только для шифрования данных и не могут быть использованы для аутентификации.



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

Приложение, отправляющее сообщение, помещает в заголовок сообщения имя приложения и имя пользователя (user ID), связанного с этим приложением. Приложение, получающее сообщение, на основе этих данных производит идентификацию и аутентификацию (для надежной защиты WebSphere MQ этого недостаточно и можно легко подставить нужные данные, если знать о такой проверке).Во время старта канала, канальный агент (message channel agent - MCA) может проверять аутентификацию партнера. Это взаимная аутентификация предполагает, что посылающий и принимающий канальные агенты обмениваются сообщениями и проверяют друг друга на подлинность.

Для обеспечения безопасности WebSphere MQ предлагается 2 уровня: безопасность на уровне связей и на уровне приложений. Безопасность на уровне связей обеспечивается непосредственно MCA, как показано на рис.13.1.

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

Работа с WebSphere MQ через Интернет/Интранет

Работа с WebSphere MQ в Интранет возможна при помощи Internet Explorer почти так же, как и с WebSphere MQ Explorer. Читатель может легко настроить работу с WebSphere MQ в интранет через Internet Explorer на основе следующих простых правил:

При инсталляции WebSphere MQ сервер необходимо отметить опцию для инсталляции компонентов: Web Administration Server;Через любой Web браузер можно подключиться к менеджеру очередей с помощью команды http://<hostname>:<port_number>, например, http://9.20.20.92:8081/ (по умолчанию порт Web Administration Server - 8081)

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

На машине с 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.

Назначение самоподписанного сертификата MQIPT для MQIPT.QM1.

Для этого необходимо импортировать сертификат в 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.

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 определяется таблицей:

Вид шифрования (CipherSpec)Набор шифров SSL (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.

Конфигурирование и работа с WebSphere MQ клиент.

Менеджер 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):

C:\> amqmcert -k MY -lC:\> amqmcert -a "certificate number" -m QM1

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


увеличить изображение
Рис. 13.4.  Проверка инсталляции сертификата


увеличить изображение
Рис. 13.5.  Добавление сертификата в хранилище сертификатов

в хранилище менеджера очередей. Необходимо

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

Нажать Start, Programs, IBM Websphere MQ, WebSphere MQ Services.Нажать правой кнопкой на менеджере очередей (в данном случае, QM1).Выбрать All tasks и затем Manage SSL Certificates.Выбрать наш сертификат и нажать кнопку Assign (назначить). Это откроет диалог "Назначение сертификата менеджеру очередей" (рис.13.6).Выбрать наш сертификат и нажать Assign. Можно увидеть в окне сертификатов помеченную иконку нашего сертификата (рис.13.7). Менеджер очередей будет посылать этот сертификат во время "SSL рукопожатия". Нажать OK.


увеличить изображение
Рис. 13.6.  Назначение сертификата менеджеру очередей


увеличить изображение
Рис. 13.7.  Проверка помеченной иконки сертификата

Когда QM1 посылает зашифрованный сертификат QM2, QM2 необходима авторизация сертификата для аутентификации QM1. Это делается на следующем шаге.

Перед тем как добавить сертификат

Перед тем как добавить сертификат в QM2, необходимо знать какой сертификат добавляется.

Для этого следует:

Открыть Internet ExplorerПерейти к Tools, Internet Options, выбрать Content tab, нажать на Certificates.Сделать двойной клик на нашем сертификате, затем выбрать закладку Certification Path. Можно увидеть путь сертификации нашего сертификата. В данном случае это:

GlobalSign Root CA



GlobalSign Primary Class 1 CA



GlobalSign PersonalSign Class 1 CA

Запомнить это и нажать последовательно OK, Close, OK.

Теперь необходимо добавить эти три сертификата в QM2. Для этого нужно сделать:

Нажать кнопки Start, Programs, IBM Websphere MQ, WebSphere MQ Services.Нажать правую кнопку на QM2.Выбрать All tasks, Manage SSL Certificates ...Нажать на Add. Это покажет список всех сертификатов в Windows.Изменить значение Certificate Store с All на ROOT.Выбрать GlobalSign Root CA и нажать на Add (рис.13.8). Это добавит сертификат и вернет нас назад к Менеджеру Сертификатов.


увеличить изображение
Рис. 13.8.  Добавление ROOT сертификата в хранилище сертификатов QM2

Нажать Add снова.Изменить значение Certificate Store на Certification Authority (CA)Выбрать оба класса (нажав CTRL) GlobalSign Primary Class 1 CA и GlobalSign PersonalSign Class 1 CA, как это было определено в начале шага 6 (рис.13.9).Нажать ADD, OK.


увеличить изображение
Рис. 13.9.  Добавление двух сертификата в хранилище сертификатов QM2

для получения SSL сертификата

Повторить Шаг 2 и Шаг 3 для получения SSL сертификата для QM2. Поскольку первый сертификат уже добавлен к WebSphere MQ серверу, можно добавить последовательно сертификаты, используя графический интерфейс вместо командной строки.Нажать Start, Programs, IBM Websphere MQ, WebSphere MQ Services.Нажать правой кнопкой на менеджер очередей (в данном случае, QM2).Выбрать All tasks и далее Manage SSL Certificates.Нажать на Add. Это покажет список всех сертификатов Windows.Изменить наше хранилище сертификатов (Certificate Store) с All на MY (текущий пользователь).Должен быть виден сертификат (рис.13.10), присланный на наш e-mail адрес GlobalSign Class 1 CA. Проверить по серийному номеру, что будет выбран новый сертификат, а не один из тех, что уже назначен для QM1. QM1 уже имеет инсталлированный сертификат, проверить его серийный номер для выбора правильного сертификата для использования в QM2.


увеличить изображение
Рис. 13.10.  Выбор сертификата для QM2

Выбрать сертификат, присланный на наш e-mail адрес, и нажать Add. Это добавит сертификат в хранилище сертификатов менеджера очередей и его можно будет увидеть в списке.Повторить шаг 5 для назначения сертификата QM2.Как и раньше, повторить шаг 6 для добавления SSL- сертификата в хранилище сертификатов менеджера, на этот раз в QM1.

Настройка SSL - свойств для каналов WebSphere MQ

Для каждого канала QM1.QM2 и QM2.QM1 в WebSphere MQ Explorer перейти на свойства и нажать закладку SSL для отправляющего и принимающего каналов.На канале-отправителе в свойствах выбрать закладку SSL и в ней выбрать, например, TRIPLE_DES_SHA_US из выпадающего меню шифров (рис.13.11). Нажать OK.На канале-получателе в свойствах выбрать закладку SSL и в ней выбрать TRIPLE_DES_SHA_US из выпадающего меню шифров. Отметить значок "Всегда идентифицировать сторону, инициирующую соединение". Нажать OK.

увеличить изображение
Рис. 13.11.  Выбор алгоритма шифрования в канале

Стартовать канал-отправитель и нажать кнопку Обновить (Refresh). Статус канала должен быть running.

Тестирование

Для тестирования можно остановить каналы, убрать в одном из них настройку SSL (CipherSpec установить в none) и попробовать стартовать каналы. Успешного старта отправляющего канала не произойдет, и он будет оставаться в состоянии retry. Вернув настройку SSL в канале в прежнее состояние, каналы можно успешно стартовать. После старта каналов следует передать сообщение, например, на менеджере QM1 командой:

amqsput TO.QM2 QM1

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

Для проверки шифрования в канале после отправки сообщения нужна специальная программа-перехватчик сообщений. Ведь в очередях на отправку и прием сообщения хранятся в незашифрованном виде. Такая программа может быть написана на C++ или Java как channel-exit программа для перехвата сообщений по порту 1515 для QM1 и по порту 1516 для QM2. В перехваченных сообщениях будет видно, что они зашифрованы. Написание такой программы читателю предлагается проделать самостоятельно или придумать другой способ проверки шифрования сообщений с помощью SSL-защиты на каналах менеджеров.

Заключительные замечания.

Данная методика рекомендуется для практической работы под Windows. Освоив ее, читатель без труда сможет настроить SSL на UNIX, OS/390, OS400, OS/2 и др. платформах с помощью документации [24], [26] и специалистов с www.mqseries.net.Существует альтернативный метод создания и использования самоподписанных сертификатов. Если имеется инсталлированные WebSphere Application Server и/или IBM HTTP Server, то можно сгенерировать собственный самоподписанный сертификат для такого демонстрационного примера без необходимости затребования сертификата из CA такого как GlobalSign.

Настройка 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. Другими важными и полезными опциями являются:

Опция MSGACCESS(NONE | DESC | RETRY | DATA | DELETE) задает режимы работы с сообщениями и функциями и, в частности, опция DELETE позволяет удалять сообщения и использовать все функции работы с сообщениями; QUEUE NAME и CHANNEL NAME позволяют задать имена очередей и каналов для мониторинга (* указывает, что мониторятся все объекты данного менеджера); Имя агента AGENT NAME (8 символов) необходимо задать, если мониторятся менеджеры с одинаковыми именами MANAGER NAME на разных серверах; Опция PERFORM STARTMON SAMPINT(300) HISTORY(YES) указывает, что осуществляется сбор статистических данных с помощью Historical Data Collection c заданным интервалом мониторинга (при большом числе объектов рекомендуется не менее 60 сек).

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

Выбираем вершину, для которой определяем пользовательский взгляд, и сохраняем в меню File новое рабочее пространство кнопкой Save WorkSpace As, например, с именем MyWorkSpace Выбираем кнопку с вариантом отображения WorkSpace – блокнот, таблица, график, гистограмма и т.д. и перемещаем её на наше MyWorkSpace по технологии drag and drop.

Правой кнопкой мыши открываем свойства 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.

Возвращаемся в свойства WorkSpace, задаем при необходимости фильтры, стиль оформления, название и нажимаем OK.

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

Candle Management Server (CMS) - сервер сбора информации от агентов; Candle Net Portal Server (CNP) - сервер отображения результатов, оповещения пользователей и настройки мониторинга КИС со своими клиентами; CNP Client (desktop and browser options) - рабочая станция администратора Omegamon; Candle Management Workstation (CMW) – специальная рабочая станция администратора Omegamon (для особо-тонких настроек и анализа); Контролируемые системы – компьютеры КИС, на которых работают агенты 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. Общая последовательность действий следующая.

На SQL server создается база данных, например, CandleWarehouse. На сервере CMS создается data source с именем Candle Data Warehouse при помощи ODBC Administrator для доступа к базе данных CandleWarehouse пользователю Candle c паролем Candle Инсталируется Warehouse Proxy агент на CMS сервере. Осуществляется настройка History Collection Configuration через CMW или CNP client (меню Edit => History Configuration) и нажимается кнопка Start Collection. Пример настройки параметров приведен на рис.14.9. Осуществляется анализ накапливаемой информации на SQL server и разработка различных видов отображения информации. Например, на основе Microsoft Access можно получить различные графики и гистограммы потоков информации (message count) на различных серверах, например, как показано на рис.14.10.

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

---

---