Компания IBM
Опубликован: 14.12.2004 | Доступ: свободный | Студентов: 1482 / 131 | Оценка: 4.36 / 3.98 | Длительность: 16:32:00
ISBN: 978-5-9556-0031-4
Специальности: Системный архитектор
Лекция 13:

Брокер сообщений WebSphere BI Message Broker

< Лекция 12 || Лекция 13: 1234 || Лекция 14 >
Аннотация: Для построения законченного интеграционного решения на основе очередей сообщений необходимо реализовать ряд дополнительных функций, включая подсоединение приложений к транспортной среде, трансформацию и маршрутизацию передаваемых данных. Многие дополнительные функции могут быть выполнены при помощи интеграционного брокера и адаптеров. В данной лекции описаны архитектура и функции интеграционного брокера WebSphere Message Broker, принципы построения, средства программирования и администрирования брокера сообщений.
Ключевые слова: топология, соединение точка-точка, шлюз, интеграция, точка-точка, ПО, минимум, адаптер, брокер, SAP, EDI, топология типа шины, функции интеграционного решения, подключение, транспортировка, процессы обработки, связь, СУБД, Oracle, SQL, server, программное обеспечение, инструментарий, интерфейс, API, JDBC, базы данных, пункт, функция, механизмы, очередь, WebSphere MQ, преобразование, оболочка, затраты, развертывание, диапазон, шаблон, бизнес-процессы, откат, информация, приложение, место, встраивания, пропускная способность, сервер, ядро, анализ, репозиторий, преобразование форматов данных, XML, маршрутизация информации и данных, метод адресации, взаимодействие потока сообщений с базами данных, ODBC, Задача синхронизации, класс, брокер сообщений, средства разработки, основные компоненты, WebSphere BI Message Broker, сервер конфигурации, Configuration Manager, графическая среда, Message Broker Toolkit, управляющие, DB2, исполнение, архитектура WebSphere Message Broker, масштабируемость, поток, конструирование, message flow, сообщение, обработчик, направленный граф, входной, парсер, список, группа, ESQL, домен, разбиение, JMS, MRM, NEON, BLOB, repository, Java, IBM, поле, выражение, объект, значение, переопределение, администрирование, средства программирования и администрирования брокера сообщений, представление, broker, application, development, integrator, dtd, Message Flows, administration, пользователь, администратор, Unix, операции, вероятность, агент, thread, support, LDAP, FTP, CICS, client, XSLT, EJB, FIX, workflow, мониторинг, запрос, шина, Enterprise Services Bus, ESB

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

Топология интеграционного решения отражает различные способы взаимодействия приложений (рис.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 || Лекция 13: 1234 || Лекция 14 >