Курс лекций "Интеграция приложений на основе WebSphere MQ"

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

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

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

Для упрощения разработки дополнительного ПО часто используются специализированные выделенные программные компоненты: адаптеры и брокеры. Адаптеры обеспечивают преобразование специфических интерфейсов и данных конкретного приложения в интерфейсы и данные стандартной интеграционной среды. Настройка интерфейсов, адресной информации и процедур трансформации вместо написания кода, позволяют ускорить внедрение интеграционного решения. Типичными примерами являются адаптеры для распространенных прикладных систем, таких как SAP R/3, баз данных, электронной почты Lotus Notes, специализированных систем передачи информации EDI, ACORD, SWIFT.

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

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

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

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

Компоненты подключения называются "адаптерами" (рис.12.2). Это предварительно созданные программные компоненты, которые обеспечивают коммуникацию со специфическими приложениями, такими, как SAP R/3, и технологиями, например, с СУБД Oracle или MS SQL Server. Преимущества этих адаптеров состоят в том, что они позволяют уменьшить объем времени и ресурсов, затрачиваемых на поддержку коммуникации с приложениями и системами, поскольку эти функции уже встроены в данное программное обеспечение. В составе интеграционной среды должен быть набор адаптеров для различных приложений и технологий. В качестве составной части адаптеры должны иметь инструментарий разработки, который позволяет создавать новые адаптеры и настраивать старые.

Адаптеры дают возможность соединяться с приложениями через собственный программный интерфейс API приложения, либо с помощью технологий, использующих стандартизованные методы доступа (например, интерфейс JDBC вызывает различные базы данных Oracle, MS SQL). Адаптеры включают средства управления событиями, которые уведомляют оболочку интеграции о произошедшем в приложении событии. Кроме того, адаптеры управляют обработкой событий между абонентскими приложениями на основе модели публикации-подписки. В зависимости от выбранной модели развертывания, они могут также управлять функциями преобразования (преобразованием в/из конкретного формата, используемого организацией для бизнес-объектов). Все адаптеры характеризуются высокой эффективностью и большой функциональностью, которая способна удовлетворить самые сложные требования. Все адаптеры включают стандартизованные средства управления ошибками, инструменты для регистрации и отслеживания.

Рис. 12.2. Компоненты интеграционного адаптера

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

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

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

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

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

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

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

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

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

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

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

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

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

Интеграционный брокер и требования к его функциональности

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

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

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

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