Meloci.ru

Как работает интеграционная шина

Блог сурового челябинского программиста

Are you aware how much time I’ve spent learning for details of Java? Thread management, dynamics, CORBA.

четверг, 16 февраля 2012 г.

Два подхода к построению интеграционной шины предприятия

На мой взгляд можно выделить два подхода к построению интеграционной шины предприятия:

  • “от интегрируемых систем”;
  • “от реализуемых процессов”.

Давайте рассмотрим данные подходы подробнее.

Подход “от интегрируемых систем”

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

У данного подхода есть следующие плюсы:

  1. Завязанность на системы, а не типы сообщений. Обычно количество интегрируемых систем в разы меньше количества передаваемых типов сообщений.
  2. Легкость подключения новых систем-приемников: для подключения новой системы-приемника достаточно внести данные в таблицу маршрутизации.
  3. Простота реализации системы мониторинга интеграционного решения: данные для системы мониторинга можно генерировать в одном месте – в маршрутизаторе (данный пункт, впрочем, можно принять лишь с оговорками, т.к. есть данные, которые генерируются только в адаптерах интегрируемых систем).
  4. Простота поддержки решения. Так как все сообщения проходят через единый маршрутизатор, то всю логику передачи сообщений и отслеживания зависимостей между сообщениями можно реализовать в одном месте – в данном маршрутизаторе.
  5. Разделяемость системы между разработчиками. Так как ядро системы и все адаптеры независимы друг от друга (связь обеспечивается только через выделенные и описанные интерфейсы), то задачи по их разработке могут быть разделены между программистами, что позволяет распараллелить процесс создания и внедрения интеграционного решения.

У данного подхода есть следующие минусы:

  1. Решение применимо только для реализации унифицированной логики передачи сообщений, т.е. если присутствуют общие для всех или большинства сообщений правила отслеживания зависимостей и трансформации. В случае, если разные типы сообщений имеют абсолютно разную логику отслеживания зависимостей и управления обменом, ее придется либо выносить в адаптеры, что нивелирует преимущество 4, либо вообще будет невозможно реализовать.
  2. Данная схема подходит для реализации асинхронного обмена. В случае синхронного либо смешанного обмена трудоемкость в реализации данного подхода значительно возрастает.
  3. Может иметь место снижение производительности решения. Например, в случае если сообщение в каждую из систем-приемников должно передаваться в отдельной транзакции, требуется разделение системы-источника, ядра и систем-приемников очередями. Данные очереди могут стать узким местом системы.

Подход “от реализуемых процессов”

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

У данного подхода есть следующие плюсы:

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

У данного подхода есть следующие минусы:

  1. Завязанность на типы сообщений. Обычно количество типов сообщений в разы больше, чем интегрируемых систем. При подключении новой системы-источника к шине необходимо осуществлять маршрутизацию сообщений по типам и для каждого типа сообщения реализовывать свой процесс обмена.
  2. Если для нескольких типов сообщений должна быть реализована одинаковая логика обмена, то возможно дублирование кода и/или настроек шины.
  3. Процессы передачи сообщений зависят от адаптеров систем и могут зависеть друг от друга, а так же от служебных процессов. Наличие таких зависимостей снижает степень распараллеливания процесса разработки и внедрения интеграционного решения. Разработчики одних компонентов зависят от результатов работы разработчиков других компонентов интеграционного решения.

Выбор подхода осуществляется по следующему алгоритму:

  1. Получить от аналитиков список и описание интегрируемых систем и типов сообщений.
  2. Получить от аналитиков список и описание бизнес-процессов, в которых участвуют требующие интеграции системы.
  3. Если процессы тривиальны и систем гораздо меньше чем типов сообщений, обмен преимущественно асинхронный, а так же требуется передача одного сообщения в несколько систем – выбираем первый подход. Определяемся с политикой управления транзакциями.
  4. Если процессы подразумевают преимущественно синхронный обмен, при этом процессы комплексные, т.е. прохождение сообщения зависит от результатов его обработки в системах-приемниках, то выбираем второй подход. Аргументом в пользу данного подхода может являться еще и тот факт, что количество типов сообщений сопоставимо с количеством интегрируемых систем.

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

Читать еще:  Как называется шнур внутри шины

Интеграция бизнес-приложений, что это? Спросим у специалиста?

В сети интернет много разной информации на такие темы, как интеграция бизнес-приложений, интеграционная шина данных, корпоративная шина данных, сервисная шина предприятия, ESB и так далее. Может показаться, что это всё разные темы, но, на самом деле, речь идёт об одном и том же. Поговорим на эту тему с Дмитрием Чубом, руководителем департамента интеграционных решений компании «ИТ Специалист», одного из лидеров на украинском рынке интеграции бизнес-приложений.

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

Вы сказали, что работаете руководителем департамента интеграционных решений. Что это за департамент?

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

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

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

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

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

Что эти решения предоставляют клиенту? Или спросим иначе, зачем клиенту это нужно?

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

Первое:

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

Второе:

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

Третье:

Есть возможность повторного использования решения другими системами, которые нуждаются в этих же данных.

Четвёртое:

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

Довольно распространенное название для таких решений на рынке, как украинском, так и в мировом масштабе — интеграционная шина данных (ESB – Enterprise Service Bus).

Может ли функционировать ИТ-инфраструктура, к примеру, банка без таких интеграционных решений?

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

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

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

Пример первый:

Выдача кредита в банке в онлайн режиме. Очень востребованная услуга! Что происходит с такой услугой в современном мире? Выдача подобных кредитов происходит в течение очень короткого срока.

Перед выдачей кредита банку необходимо получить информацию о клиенте из таких систем, как:

  • АБС (автоматизированная банковская система);
  • Бюро кредитных историй;
  • Электронный архив;
  • Другие системы, которые предусмотрены банком.

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

Во всех банках решения о предоставлении кредита принимаются по-разному. Но всегда на основании этих структурированных данных.

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

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

Второй пример:

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

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

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

Какой инструмент вы используете для своих интеграционных решений?

Для реализации интеграционных решений мы используем комплексные решения от компании IBM.

Компания IBM предоставляет продукт под названием IBM Integration Вus (IIB). Это современная среда разработки и конфигурирования интеграционных решений.

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

Читать еще:  Какой герметик для шин лучше

Перечислите, пожалуйста, услуги, которые предоставляет ваша компания.

Наша компания работает с клиентами с различной готовностью (зрелостью) интеграционных решений – как с ИТ-инфраструктурой, где, как говорят, «конь не валялся», до уровня технической поддержки и развития уже реализованной интеграционной среды:

  • Внедрение интеграционной шины данных с нуля. Мы проектируем и разворачиваем необходимую инфраструктуру. Разработка и тестирование интеграционных приложений. Подготовка технической документации. Проводим обучение сотрудников. Услуги аутсорсинга.
  • Развитие интеграционной шины данных: модернизация интеграционных приложений с целью получения новых функций или повышения производительности.
  • Техническая поддержка интеграционной шины данных. Такая поддержка состоит из поддержки инфраструктуры шины данных и поддержки интеграционных приложений.
  • Мониторинг интеграционной шины данных, который состоит из мониторинга инфраструктуры и мониторинга производительности интеграционных приложений.
  • Гарантийный сервис реализованных интеграционных проектов.

Как начать сотрудничество с вашей компанией?

Для этого вам нужно связаться с нашими менеджерами по продажам по телефону или электронной почте. Вам будет задан ряд вопросов и оговорено время встречи.

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

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

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

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

Информацию предоставил руководитель департамента интеграционных решений «ИТ Специалист» Дмитрий Чуб.

Вопросы задавал контент-маркетолог Александр Куберский.

В чём заключается отличие таких способов взаимодействия приложений, как шлюз и шина?

Читала статью про способы взаимодействия приложений. И что мне осталось совершенно непонятным, это как различаются топологии интеграционного решения “шлюз” и “шина”:

Буду благодарна, если кто-нибудь пояснит разницу между ними.

1 ответ 1

В статье “немного” ошиблись с определениями, отсюда и непонятки. Дело в том, что та статья написана, по сути, про одно конкретное решение – и все остальное приведено только для общего сведения.

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

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

Более сложные варианты дают возможность доставки сообщений по системе pub/sub (публикатор – подписчик).

Интеграционная шина может быть построена вокруг центрального узла (или нескольких узлов), где “крутится” маршрутизатор (см. далее) – или же быть распределенной, существуя в виде кучи адаптеров (см. далее) на стороне каждого приложения с общей базой адресов.

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

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

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

Интеграционный шлюз – это маршрутизатор сообщений, связи которого можно поделить на “внешние” и “внутренние”.

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

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

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

Адаптер – это маршрутизатор сообщений, разные связи которого работают по разным протоколам.

Брокер – это маршрутизатор сообщений повышенной крутизны сложности. К примеру, он может работать с децентрализованной шиной. Или выполнять хитрые трансформации, выступая универсальным центральным адаптером.

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

Однажды я написал свой интеграционный шлюз просто потому что КРОК 2 месяца отказывался предоставлять нашей подсистеме второй адрес на своей интеграционной шине.

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

Читать еще:  Как заменить шпильку крепления шины на бензопиле

К примеру, WebSphere Message Broker имеет в своем названии слово “Брокер” (и заслуженно носит его за свою непомерную сложность крутизну) – поэтому и называть его надо брокером, а не маршрутизатором сообщений, адаптером, шлюзом или шиной.

С другой сторону, если на основе WebSphere Message Broker был сделан свой проект по работе со СМЭВ, который был назван “шлюз для работы со СМЭВ” – то и называть его надо шлюзом, несмотря на то, что он является еще и адаптером и маршрутизатором сообщений.

Или, к примеру, сама СМЭВ по сути является простейшей интеграционной шиной, а внутрях крутится на WebSphere Message Broker (я видел типичные для него сообщения об ошибках) – но называть ее надо СМЭВ, а то не поймут.

Стоит отметить рост подобных запросов именно от бизнеса.
Тренд смещается от ИТ для ИТ,
к ИТ для бизнеса.

Основных схем интеграции две : оркестровка и хореография. Оркестровка — это большая централизованная схема, где всем управляет оркестратор. Хореография — схема, где элементы распределённые, децентрализованные, и каждый, как танцор, выстраивает свой танец, взаимодействуя с другими. На уровне бизнеса схемы одинаковы, а вот на технологическом уровне — это разные процессы.

Сложности интеграции

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

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

Так когда нужна шина?

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

Перед внедрением технологии всегда важно верно оценить затраты, которые предприятие готово понести на начальном этапе. Многие аналитические компании, такие как Forrester и IDC, отмечают: более половины провалов проектов вне зависимости от масштабов компаний объясняются недооценкой сложности интеграции.

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

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

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

Открытый исходный код: спасение или угроза?

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

Компания,
много лет присутствующая на рынке,
отвечает за то, что делает.

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

Open-source как бизнес-модель, приносящая клиентам инновации, выигрывает. Продакт-менеджеры постоянно находятся в интернациональном сообществе разработчиков, черпая оттуда инновации, когда новый код возникает в ответ на бизнес-потребность — и в этом разительное отличие от проприетарных конкурентов и последователей. Компания-клиент иногда не может себе позволить штат даже из 50 программистов — а так она получает доступ к сотням тысяч специалистов. В современных экономических условиях это особенно важно.

Считаем затраты

Единственное, что может повлиять на интеграционные затраты, и не всегда в сторону роста, — потребности вашей компании. Например, автоматизация процессов с повторным использованием существующих технологий существенно снизит затраты и поспособствует быстрому появлению новых процессов, как и было у «МигКредит». А вот внутренних сотрудников, которые занимаются поддержкой и разработкой шины, у компании нет, всё на аутсорсе — это выгоднее.

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

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

Ссылка на основную публикацию
Adblock
detector