Брокер интеграции приложений

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

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

Прежде всего, отметим кардинальный подход, требующий полной замены существующих систем. Это позволяет заранее предусмотреть и заложить взаимосвязи между отдельными компонентами уже на этапе проектирования. Однако за достоинства новой технологии придется расплачиваться потерей уже сделанных наработок, людских и материальных инвестиций. Типичные примеры подобного подхода — интеграция на базе комплексной системы ERP или на базе «домашней» разработки с использованием объектной технологии. Кроме неизбежных потерь и трудностей переходного периода принцип полной замены не решает проблем интеграции для будущих усовершенствований: новая система, как правило, не покрывает всю прикладную функциональность, которая может потребоваться предприятию, — следовательно, проблема интеграции остается.

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

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

Типичные интеграционные задачи

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

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

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

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

Компоненты и топология интеграции

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

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

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

Рис. 1. Различные архитектуры интеграции

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

Использование адаптеров и коннекторов обеспечивает преобразование специфических интерфейсов и данных конкретного приложения в интерфейсы и данные стандартной интеграционной среды (например, данные из таблиц реляционной базы данных в сообщения транспортной инфраструктуры). Прикладные программные интерфейсы API позволяют встроить в приложения код, позволяющий работать с транспортной инфраструктурой. Настройка интерфейсов, адресной информации и процедур трансформации, применяемых в адаптерах вместо написания кода, позволяет ускорить внедрение интеграционного решения. Типичные примеры — адаптеры для подсоединения известных прикладных систем, таких как SAP R/3 и Siebel, технологические адаптеры, позволяющие работать с базами данных DB2, Oracle, Microsoft SQL Server, плоскими файлами, системами электронной почты, наконец, адаптеры для специализированных сетей передачи деловой информации EDIFACT, ACORD, SWIFT, RosettaNet.

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

Стандартное интеграционное решение от IBM базируется на транспортном слое системы очередей сообщений WebSphere MQ, многочисленных адаптерах WebSphere BusinessIntegration Adapters и интеграционном брокере WebSphere MQ Integrator [1].

Транспортный базис интеграционного решения

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

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

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

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

Интеграционные адаптеры

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

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

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

Интеграционный брокер

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

Рис. 4. Интеграционный брокер

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

Преобразование форматов данных

Передаваемые между системами данные могут иметь различную структуру, оформленную в самых разных форматах. На практике встречаются открытые стандартизованные форматы (например, XML), специфические для конкретной отрасли форматы (EDI или SWIFT), относящиеся к конкретной прикладной системе (SAP R/3) или уникальные форматы, разработанные для конкретного приложения. Брокер должен обеспечить совместимость форматов для всех участвующих в обмене сторон и уметь оперировать данными в форматах самых разных типов.

Маршрутизация информации и данных

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

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

Взаимодействие с базами данных и другими системами

Обмен данными, обобщенно говоря, между внешней динамической транспортной системой и средой внутренних данных прикладных систем является наиболее часто повторяющимся действием. Подобный обмен должен быть реализован на общих для обеих сред языковых и интерфейсных средствах; необходима поддержка стандартов SQL, ODBC, XML. Правда, надо заметить, что серверы баз данных имеют собственные специальные средства для сбора, передачи и загрузки данных, а также средства репликации данных. В отличие от интеграционных брокеров инструменты СУБД ориентированы на работу только с базами данных. Если сравнивать возможности средств интеграционного брокера и средств сервера баз данных, то брокеры часто имеют более ограниченные возможности в использовании всех механизмов СУБД, в частности, в использовании групповых операций и в поддержке целостности модели данных. В то же время брокеры сообщений предоставляют более надежные транспортные механизмы, гибкую маршрутизацию и систему обработки и реакции на события.

Средства разработки, производительность и масштабируемость

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

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

Архитектура WebSphere MQ Integrator

За свою историю данный программный продукт имел версии с разными именами: MQSeries Integrator [2], MQ Integrator, MQ Integation Broker, MQ Message Broker. Основные компоненты WebSphere MQ Integrator: система исполнительных брокеров, сервер конфигурации Configuration Manager и универсальная графическая среда разработки и администрирования ControlCenter (рис. 5). Брокеры, отвечающие за исполнение потоков обработки, являются исполнительной средой. Каждый брокер имеет собственную базу данных, хранящую часть данных главного репозитория. Многопроцессная и многопоточная архитектура ядра брокера обеспечивает масштабируемость. Служба форматирования сообщений позволяет брокеру разбирать сообщения на отдельные поля и оперировать с сообщениями как со сложно структурированными документами.

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

Поток обработки сообщения и его визуальное конструирование

Обработка сообщения, попавшего в брокер, определяется потоком обработки сообщения (message flow), представляющим собой направленный граф. Его узлы — это отдельные шаги или процедуры обработки, а ребра — пути сообщений в потоке между отдельными стадиями обработки (рис. 6). Фактически логическое представление процесса обработки данных и перехода контроля между стадиями обработки совпадет с физическим процессом внутренней трансформации сообщения на стадиях обработки. Поток обработки состоит из последовательности операций над сообщением и конструируется при помощи набора существующих стандартных обработчиков. Обработчики WebSphere MQ Integrator — это параметрически настраиваемые процедуры, реализующие отдельный шаг или специализированную функцию процесса обработки. В свойствах процедур-обработчиков определяются параметры, необходимые для исполнения данного потока. Скажем, если обработчик читает сообщения из очереди WebSphere MQ, то в качестве параметра определяется имя очереди. Если другой обработчик предназначен для обращения к внешней базе данных, то среди его параметров будут названия базы, таблиц и полей. Обработчики имеют точки входа и выхода — так называемые «терминалы». Входные и выходные терминалы обработчиков связываются соединениями, образуя направленный граф, который реализует пошаговую последовательность обработки сообщения.

Рис. 6. Пример потока обработки сообщений

Поток обработки стандартно начинается с получения сообщения из очереди через входной обработчик (Input) и заканчивается рассылкой сообщений другим системам через один или несколько выходных обработчиков (Output), записью в базу данных, или публикацией сообщения для группы подписчиков по совпадению темы или просто уничтожением присланного сообщения. Чаще всего для связи с внешними системами используется транспорт WebSphere MQ, а входная очередь является сборным ящиком для приема информации в виде сообщений, поступающих извне. В других случаях процедура обработки может стартовать при получении данных с телеметрических устройств через протокол SCADA, с мобильных устройств при помощи MQSeries Everyplace или начинаться с запуска произвольного входного обработчика собственного написания. Важной задачей на стадии приема сообщения через входной обработчик Input, кроме чтения пришедшего сообщения из очереди, является правильная интерпретация его содержимого, отнесения к соответствующему домену, разбор сообщения в соответствии с типом и форматом на отдельные поля. При этом, для различных доменов сообщений (например, XML или SAP Idoc) существуют различные компоненты анализа и разборки структуры сообщения — парсеры, которые используются входным обработчиком. Среди параметров, определяющих поведение потока обработки и отдельных обработчиков, содержатся важнейшие определения о транзакционности данного потока обработки, о постоянстве или непостоянстве создаваемого сообщения, способе передачи контекста и идентификационной информации из исходного сообщения в новые сообщения, создаваемые в процессе обработки.

Целая группа обработчиков служит для маршрутизации и ветвления процесса обработки. Другие обработчики предназначены для реализации различных синтаксических и семантических проверок. Например, обработчик фильтра разделяет поток на отдельные ветви в зависимости от условия фильтрации. Условные переходы с динамическими и статическими назначениями внутри потока обеспечиваются обработчиками RouteToLabel и Label. Для реакции на возникающие ошибки и обработку исключительных состояний существуют обработчики TryCatch и Throw. Трассировка и проверка корректности потока и структуры проходящих сообщений осуществляются соответственно обработчиками Trace и Check, а обработчик FlowOrder определяет порядок прохождения отдельных ветвей потока обработки. Для взаимодействия с базами данных существуют специализированные обработчики, позволяющие визуально назначать связи и преобразования между полями базы данных и полями сообщения. Наиболее часто используемым и универсальным по возможностям является обработчик Compute, позволяющий писать разнообразные программы-скрипты на языке ESQL, расширении SQL3 [3].

Домены сообщений

На стадии первичной обработки любого сообщения, попавшего в WebSphere MQ Integrator, происходит его отнесение нужному домену (XML, JMS, MRM, NEON, BLOB) и разбор на отдельные поля. Некоторые типы сообщений WebSphere MQ Integrator умеет распознавать и обрабатывать динамически без использования предварительно занесенных в репозиторий метаданных, например, динамически происходит обработка так называемых «хорошо определенных» XML-документов. Для других типов XML-документов требуется предварительное занесение структуры в репозиторий, например, путем экспорта DTD документа. Среди доменов особо выделяется MRM (Message Repository Manager), являющийся основным репозиторием. MRM-сообщения могут иметь произвольную и очень сложную структуру; инструментальные средства брокера позволяют разрабатывать новые MRM-форматы.

Сообщения, созданные приложениями при помощи интерфейса JMS, могут относиться к нескольким типам языка Java: текст, потоки, карты и объекты Java. Опционально WebSphere MQ Integrator включает технологию разбора и обработки сообщений, лицензированную у компании NEON. Наконец, содержание неструктурированных сообщений и сообщений с неизвестной структурой трактуются как большие бинарные объекты и относятся к домену BLOB.

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

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

Язык работы с сообщениями

Язык скриптов ESQL, развивающий широко используемый процедурный язык SQL3, дополнен средствами манипулирования сообщениями разнообразных форматов. ESQL используется в трех основных обработчиках — Compute, Filter, Database — и позволяет изменять содержание и служебные данные входного сообщения, создавать новые сообщения и обновлять внешние базы данных. Важной особенностью ESQL, отличающей его от SQL3, являются ссылочные конструкции, позволяющие адресовать отдельные поля и элементы в структурированном дереве сообщения, использовать разные методы для выделения отдельные группы элементов и методы навигации по дереву сообщения.

Администрирование брокера

Для поддержки жизнедеятельности брокера требуются разнообразные инструменты, начиная со средств разработки новых форматов и процедур обработки (в том числе, средств тестирования и отладки) и заканчивая средствами администрирования и мониторинга повседневной работы брокера и диагностики проблем. В WebSphere MQ Integrator используется интегрированная среда управления, являющаяся универсальным инструментарием и для разработчика, и для администратора. В среду управления входят компоненты, объединенные общей графической оболочкой и поддерживающие весь цикл работы брокера: определение форматов сообщений; разработка процедур обработки; режим тестирования; назначение разработанных процедур на исполнение конкретному брокеру; динамическое распространение изменений на уже работающие процедуры; определение общей топологии среды распределенных брокеров; мониторинг состояния действующих брокеров и потоков обработки; журналирование административных операций.

Расширение функциональности

WebSphere MQ Integrator можно расширить путем добавления новых обработчиков для программирования типичных функций. При этом предусмотрен стандартный инструментарий, позволяющий создавать новые разработчики на языках Cи и Java. Кроме того, доступны многочисленные дополнительные обработчики, разработанные партнерами, заказчиками и специалистами IBM, например, обработчики для посылки электронной почты, или посылки-приема файлов по FTP, выполнения XSLT преобразований и др. Внутренняя функциональность брокера может быть дополнена путем встраивания парсеров для работы со специализированными форматами сообщений. Репозиторий брокера позволяет работать с сообщениями практически любой сложности, однако использование специализированного парсера может оказаться более эффективным. Примером специализированного парсера могут служить компоненты для работы с документами SAP Idoc системы R/3.

Взаимодействие с системами workflow

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

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

Заключение

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

В основе интеграционного решения от IBM решения лежит базисная технология очередей сообщений WebSphere MQ [4] — асинхронная система передачи данных с механизмами гарантированной доставки. Поверх базовой структуры WebSphere MQ могут быть размещены другие программные компоненты для обработки передаваемой информации и управления сложными бизнес-процессами.

Литература

1. WebSphere MQ Integrator. Programming Guide.
2. MQSeries Integrator Version 2 Technical White Paper.
3. WebSphere MQ Integrator. ESQL Reference.
4. Николай Игнатович, "IBM MQSeries: архитектура системы очередей сообщений". // Открытые системы, 1999, № 9-10.