Зачем нужна шина ESB?

Путешествие в мир сервисных корпоративных шин на IBM WebSphere ESB

Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее — ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:

  • Порядок и единообразие архитектурных связей
  • Централизованное управление
  • Конфигурация приложений на стороне сервера
  • Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
  • Протоколо-независимость разрабатываемого программного кода
  • Широкие возможности конфигурирования шины и приложений

При этом ESB обеспечивает транзакционный контроль, преобразование данных, сохранность и гарантированную доставку сообщений. Доступ ко всем сервисным службам через единую точку позволяет осуществлять конфигурирование коммуникации сервисов централизованно. Так же централизованно можно управлять сбойными событиями для массовой обработки ошибок.
Классическая топология сборки ESB – кластер, обеспечивающий горизонтальную масштабируемость и отказоустойчивость. По официальным рекомендациям, увеличение количества членов кластера увеличивает производительность более эффективно, чем наращивание мощности сервера при stand-alone топологии. Кроме этого, кластер можно перезагрузить (или его часть может отказать) без остановки обслуживания.
Обычно ESB используется как сервисная прослойка в IBM BPM, но вполне может играть ведущую роль в построении модели взаимодействия корпоративных систем как мощный интеграционный аппарат (имеется в виду ESB как надстройка над IBM WebSphere Application Server).
Это, по сути, требуется от ESB, так как это «точка сбора сервисов» — если вам нужен сервис, который будет работать с другими сервисами (возможно, внешними), то интеграцию между этими сервисами логичнее всего сделать именно на ESB. Для внешних или гетерогенных сервисов можно сделать «обертку» ESB-сервисом. Немного проиллюстрируем удобства использования «единого жилья» для сервисов:

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

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

Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика.

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

Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.

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

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

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

SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).

Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).

Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.

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

Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.

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

В статье использованы следующие изображения: 1 2 3 4 5

ESB (enterprise service bus): назначение, функционал, новые подходы к развитию

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

Что такое интеграционная шина и как она устроена

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

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

Важно

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

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

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

Читайте также  Как можно отогреть бачок омывателя?

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

Если в одну из систем потребуется внести изменения, это никак не повлияет на работу других корпоративных приложений. За все эти задачи будет отвечать только шина данных ESB [2] .

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

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

Несколько слов о том, как устроена интеграционная шина. Решение включает в себя несколько компонентов:

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

Интеграция программных модулей

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

Маршрутизация сообщений

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

Преобразование сообщений

Данные из разных систем могут быть представлены в различных форматах — XML, CSV, JSON, DBF и других. При классическом подходе «точка-точка» это затрудняет процесс «общения» приложений между собой. Сервисная шина предприятия решает проблему, преобразуя данные из неподходящего формата в подходящий. Например, если нужно отправить одно и то же сообщение и в ERP, и в CRM, ESB трансформирует данные нужным образом и передаст в соответствующие системы.

Масштабируемость

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

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

На заметку

В сервис-ориентированной архитектуре, частью которой является ESB, объединяются все API, что обеспечивает сквозную интеграцию. API — это своего рода контракт, в котором описаны условия «общения» программ между собой: входные и выходные данные, типы операций. Использование API значительно упрощает взаимодействие: он связывает воедино возможности разных сервисов, образуя доступные разным пользователям интерфейсы [4] .

Чем отличается микросервисная архитектура от традиционного подхода с ESB шиной?

Ее функциональность разбита по маленьким сервисам, каждый из которых отвечает за отдельную бизнес-задачу (решая ее в совершенстве), поддерживается одной командой и может работать изолированно от других. Централизованной базы данных здесь нет, у каждого сервиса — свое хранилище информации. ESB при этом выполняет лишь функцию транспорта, являясь по сути просто брокером сообщений. Взаимодействие между пользователем и сервисами также осуществляется через API, но программный интерфейс не содержит бизнес-логики [5] .

Независимость микросервисов друг от друга обеспечивает ряд преимуществ с точки зрения эксплуатации и развития информационной системы предприятия:

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

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

Интеграционная платформа от российского разработчика

Сегодняшний IT-рынок предлагает разнообразные решения для интеграции корпоративных приложений. Разработка команды «Севентек» 7TECH Integra отличается высокой технологичностью и надежностью, а также представлена в реестре российского ПО. Об особенностях интеграционной платформы рассказывает Алексей Феофанов, руководитель блока программных решений компании:

«При разработке платформы наша команда использовала принцип микросервисной архитектуры. Микросервисы легко встраиваются в любой IT-ландшафт предприятия, позволяют бесшовно взаимодействовать, а впоследствии — безболезненно и плавно заменять устаревшие legacy-системы. Наша платформа равномерно распределяет нагрузку и тем самым гарантирует отказоустойчивость системы. Сервисы посредством классических адаптеров реализуют логику маршрутизации, трансформации и маппинга данных, предоставляя API для публикации сервиса на API Gateway. Таким образом достигается упрощенное унифицированное взаимодействие: за одно обращение к API Gateway пользователь может получить требуемые данные из множества источников.

Все компоненты платформы, действуя в связке, обеспечивают быстрый, гарантированный и безопасный обмен данными как внутри предприятия, так и с внешними системами. Кроме того, за счет полноценного процесса CI/CD, включающего автоматическую сборку и доставку изменений до стендов разработки, отладки и продуктивной среды, мы добиваемся минимального time-to-market для выхода приложений на рынок. В процессе разработки мы используем все необходимые элементы контроля качества: unit тесты, проверки качества кода и наличия уязвимостей, автотесты с соответствующими проверками на полноту покрытия. А за счет переиспользования сервисов, платформа позволяет оперативно создавать новые приложения и цифровые продукты.

В качестве примера того, как наша платформа помогает бизнесу, можно привести кейс для компании «Дом.РФ».

Для управления потоками данных, которые используются в основных бизнес-процессах компании, «Дом.РФ» совместно со специалистами «Севентек» разработали Единую интеграционную систему управления и распространения данных (ЕИСУРД). Она предназначена для обеспечения взаимодействия с внутренними системами компании и внешними — такими, как СМЭВ, ФИАС, СПАРК, SRG, «Мобильный оценщик», Росреестр, Минкомсвязи России и др.

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

P. S. Российская технологическая компания «Севентек» специализируется на разработке и внедрении ПО с открытым исходным кодом. Специалистами компании создана и внедрена в ряде крупных корпоративных и государственных организаций Платформа цифровой трансформации. Модули платформы, включая интеграционные компоненты, передаются в виде лицензий и адаптируются под бизнес-требования Заказчика. Среди клиентов 7TECH — «Дом.РФ», Министерство культуры РФ, ФАДН России, «Алроса», АО «Российский экспортный центр».

Заметки из Зазеркалья

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

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


Примеры сценариев интеграции:

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

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

Продукт «Интеграционная шина»

Для организации взаимодействия систем предлагается следующая последовательность:

  1. Разработчик описывает интеграцию систем в специализированном редакторе, используя простую графическую нотацию.
    1. Маршрут движения сообщений представляется направленным графом, который показывает, как сообщения передаются от источников к назначениям.
    2. При необходимости можно определить сложный алгоритм маршрутизации сообщений или трансформировать сообщение при помощи процедуры на встроенном языке.
    3. Источником сообщения может быть файл, результат HTTP запроса, внешний брокер сообщений или подключенная к «Интеграционной шине» внешняя система (такие системы называются участниками взаимодействия).
    4. Полученное описание сохраняется в специальном объекте Процесс интеграции.
    5. Определяются параметры Процесса интеграции, значения которых будут определены во время исполнения (пути, адреса сервисов и пр.).
  2. Созданные разработчиком Процессы интеграции разворачиваются на сервере «Интеграционной шины».
  3. Администратору сервера доступен графический интерфейс управления «Интеграционной шиной», в котором:
    1. Задаются значения дополнительным параметрам Процесса интеграции
    2. Определяются правила подключения Участников взаимодействия к серверу «Интеграционной шины» и способ их участия в процессах интеграции
    3. Запускаются Процессы интеграции и начинают доставлять сообщения
    4. Останавливаются Процессы интеграции
    5. Доступны данные мониторинга работы Процессов интеграции: количество обработанных сообщений, ошибок и пр.

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

Подключение 1С:Предприятия к «Интеграционной шине»

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

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

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

Читайте также  Как привязать брелок Магикар а?

Взаимодействие с «Интеграционной шиной» выполняется с гарантированной доставкой сообщения, что означает:

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

Пример сценария интеграции

Офис отправляет в магазины и на сайт изменения в прайс-листе.

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

В момент изменения прайс-листа в офисе формируется сообщение, содержащее актуальный прайс-лист в формате EnterpriseData. Это сообщение отправляется в канал «ИзОфисов».

В узле «ДляВсех» все сообщения из канала «ИзОфисов» маршрутизируются по трем направлениям:

  1. Для передачи магазинам, использующим старое ПО, в формате JSON. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляМагазинов». Полученный JSON отправляется в канал «ДляМагазиновСоСтарымПО».
  2. Для передачи магазинам, использующим ПО 1С, сообщение в исходном виде отправляется в канал «ДляМагазиновНа1С».
  3. Для публикации на сайте. Преобразование из исходного XML происходит в узле вида «Транслятор» с именем «JsonДляСайта». Полученный JSON отправляется на сайт HTTP запросом в узле «НаСайт».

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

Преимущества нашей «Интеграционной шины»

После знакомства с «Интеграционной шиной» может возникнуть естественный вопрос: рынок ПО класса ESB достаточно обширен, на нем представлено немало достойных продуктов, в том числе и бесплатных; зачем же фирме «1С» делать ещё один продукт, не изобретаем ли мы велосипед?

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

  1. Мы постарались сделать наш продукт максимально простым и удобным в использовании.
  2. Мы сделали интеграцию нашего продукта с приложениями 1С максимально гладкой.
  3. «Интеграционная шина» от 1С легка в освоении для разработчиков 1С и позволит клиентам во многих случаях для настройки процессов интеграции обходиться усилиями существующих ИТ-специалистов (партнера 1С и/или своего ИТ-отдела, обслуживающего клиента).
  4. Наш продукт будет органично вписываться в экосистему 1С и позволит решить нашим клиентам задачи своего бизнеса наиболее эффективным способом.

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

Мы планируем этап бета-тестирования «Интеграционной шины» и будем рады помощи партнеров и клиентов. Чтобы участвовать в бета-тестировании продукта нажмите зелёную кнопку «Пробовать» в начале статьи.

Шины Данных (Enterprise Service Bus, ESB)

Почему компании делают выбор в пользу Шины Данных

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

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

В начале 2000 годов на рынке программного обеспечения стали появляться решения, сформировавшие кластер под названием Сервисная шина масштаба предприятия (Enterprise Service Bus, ESB), или сокращенно Шина Данных. Шина Данных – это, в первую очередь, концепция, элемент архитектуры IT-ландшафта, используемый для решения задачи интеграции разрозненных информационных систем в единый программный комплекс с централизованным управлением передачей информации и применением сервис-ориентированного подхода.

Enterprise Service Bus (ESB)

Архитектура ESB строится на 3 компонентах:

  • набор коннекторов
  • очередь сообщений
  • платформа

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

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

К основным преимуществам современных ESB-решений относятся:

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

Пример действующего решения

К настоящему времени на рынке представлено более двух десятков шин данных, однако наибольшее распространение получили следующие решения:

  • Integration Bus (IBM)
  • Oracle Service Bus (Oracle)
  • BizTalk (Microsoft)
  • ActiveMatrix Service Bus (TIBCO)
  • MuleESB (MuleSoft)
  • JBoss Fuse ESB (Red Hat)

По результатам проведенного анализа различных Шин Данных нашей компанией был сделан выбор в пользу программного продукта JBoss Fuse. В число критериев входили такие вопросы как: наличие широкого спектра адаптеров (включая работу с web-сервисами), возможности маршрутизации и трансформации сообщений, оркестровка, поддерживаемые протоколы обмена, удобство администрирования, стоимость приобретения и поддержки. Данное решение по своим функциональным характеристикам не уступает аналогам от IBM, Oracle и Microsoft, но при этом доступно для бесплатного использования (лицензия приобретается только на поддержку).

На рисунке показан пример реализации web-сервиса, который по запрошенному идентификатору выдает из базы данных информацию о клиенте. Задача решена в инструменте редактирования JBoss Fuse, входящем в состав Jboss Fuse ESB.

Заключение

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

ESB — Enterprise Service Bus

ESB (Enterprise Service Bus) — дословно можно перевести как «сервисная шина предприятия». ESB описывает вполне реальный программный продукт, в задачи которого входит упрощение вызова службы за счет управления всеми взаимодействиями на пути от потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми возможностями ESB являются преобразование сообщений и их маршрутизация. На шину ESB в архитектуре SOA возложена важнейшая задача обеспечения взаимодействия систем из слабосвязанных сервисов в сети. Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня, который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция).

Содержание

Основные функции ESB

  • Обеспечение интерфейсов взаимодействия
  • Отправка сообщений и маршрутизация
  • Преобразование данных
  • Сенсоры событий
  • Управление политиками
  • Виртуализация

Архитектура ESB

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

Достоинства и недостатки

Достоинствами ESB является:

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

К числу недостатков ESB относят:

  • Сложность реализации
  • Требует больших ресурсов.

Разработка Enterprise Service Bus

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

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

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

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

Шлюз служб

Так называемый шлюз служб является краеугольным камнем синхронной ESB. Он выступает посредником между провайдерами и потребителями служб, оказывая при этом содействие в обработке синхронных вызовов с использованием брокера. Данный шлюз открывает доступ ко всем известным службам и прокси-службам каждой из них, поэтому он является своего рода «единым окном» для потребителя, желающего вызывать любую службу у любого провайдера, который известен шлюзу. Когда Web-службы координирует шлюз, они обладают способностью к самоописанию. Каждая служба предоставляет свой интерфейс с помощью WSDL, который состоит из следующих четырех частей:

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

Web-службы шлюза, а точнее их прокси-службы являются также обнаруживаемыми. Шлюз дает такую возможность в виде UDDI-службы. Чтобы найти адрес вызова службы потребитель подает запрос в UDDI-службу шлюза список провайдеров необходимой WSDL-операции и получает обратно адрес прокси-службы шлюза для этой операции.

Читайте также  Как проверить рабочий термостат или нет ваз 2110?

Шина сообщений

Шаблон Message Bus (Шина сообщений) является основой асинхронной ESB. Шина сообщений — это набор каналов сообщений, которые настроены как пары каналов запрос-ответ. Каждая пара представляет службу, которую может вызвать потребитель, использующий шину. Потребитель посылает сообщение в очередь запросов службы и после этого выслушивает очередь ответов для получения результата. О том, кто предоставляет службу потребитель на самом деле не знает. Провайдеры служб также подсоединены к шине сообщений и прослушивают ее на наличие сообщений запросов. При наличии нескольких провайдеров службы, между ними происходит соревнование как между потребителями за получение конкретного запроса. Система сообщений, выполняемая шиной сообщений, функционирует как диспетчер сообщений и рассылает запросы провайдерам служб, оптимизируя эту рассылку в зависимости от степени нагрузки, сетевых задержек и т. д. После того как провайдер получил запрос, он выполняет службу и вносит результат в сообщение в очередь ответов, то есть провайдер и потребитель никогда не знают о месторасположении друг друга. Эта шина сообщений и является сущностью ESB.

Русские Блоги

Корпоративная служебная шина ESB

После десяти лет разработки осталась только эта архитектурная система! >>>

ESB — это аббревиатура от Enterprise Service Bus (корпоративная служебная шина), продукт сочетания технологии промежуточного программного обеспечения, веб-службы и других технологий, а также основной инфраструктуры в системе SOA. ESB — это сервисный посредник, образующий биологическую цепочку: пользователи сервиса -> Прокси сервиса ESB -> поставщики сервисов.Роль посредника различна в разных приложениях:

Разделительный посредник: заказчик не знает и не заботится о фактической идентичности поставщика услуг, его физическом местоположении, протоколе передачи и определении интерфейса.Код интерактивной интеграции извлекается за пределами бизнес-логики, а платформа ESB выполняет центральное декларативное определение. Платформа ESB реализует преобразование протоколов (WebService, Http, JMS . ), преобразование сообщений (преобразование, обогащение, фильтрация), маршрутизацию сообщений (синхронный / асинхронный, публикация / подписка, маршрутизация на основе содержимого, ветвление и агрегация . ).

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

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

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

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

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

Не делайте SOA в первую очередь для создания большой и всеобъемлющей ESB, наоборот, обратите внимание на свои бизнес-проблемы, найдите способы использовать SOA для решения бизнес-потребностей, в процессе решения этой проблемы вы увидите серию Бизнес Сервис. Эти бизнес-услуги будут создавать ценность для бизнеса. Его можно гибко собирать и динамически решать изменяющиеся потребности вашего бизнеса. В этом его ценность. Только так вы сможете сделать свой бизнес гибким и адаптироваться к изменениям по запросу. Затем в процессе сборки сервисов вы можете использовать ESB для их подключения.

ESB нужна какая-то форма каталога маршрутизации сервисов для маршрутизации сервисных запросов. Однако SOA может также иметь отдельный каталог бизнес-сервисов (каталог бизнес-сервисов), его самая основная форма может быть каталогом сервисов времени разработки, используемым для повторного использования сервисов в процессе разработки организации. Web Service Vision помещает каталог UDDI в роли каталога бизнес-сервисов и каталога маршрутизации сервисов, таким образом обеспечивая динамическое обнаружение и вызов сервисов. Такой каталог можно рассматривать как часть ESB; однако до того, как такие решения станут общими, каталог бизнес-сервисов может быть отделен от ESB.

Стандартные функции ESB

маршрутизация

Обращение

Коммуникационные технологии, протоколы и стандарты (например, IBM® WebSphere® MQ, HTTP с HTTPS)

Опубликовать / подписаться

Ответ / запрос

Пожар и забыть, событие

Синхронный и асинхронный обмен сообщениями

Определение интерфейса службы (например, язык описания веб-служб (WSDL))

Поддержка внедрения альтернативных услуг

Модель обмена служебными сообщениями, необходимая для связи и интеграции (например, модель промежуточного программного обеспечения SOAP или Enterprise Application Integration (EAI))

Каталог услуг и открытие

база данных

Агрегация услуг

Устаревшая система и адаптер приложений

Возможность подключения промежуточного программного обеспечения EAI

Отображение услуг

Преобразование протокола

Среда сервера приложений (например, J2EE и .NET)

Языковой интерфейс для вызова службы (например, Java и C / C ++ / C #)

Транзакция (атомарная транзакция, компенсация, транзакция веб-службы (WS-Transaction))

Различные установленные парадигмы доставки (например, WS-ReliableMessaging или поддержка промежуточного программного обеспечения EAI)

Аутентификация

Авторизация

Безотказность

Конфиденциальность

Стандарты безопасности (например, Kerberos и безопасность веб-служб (WS-Security))

спектакль

Пропускная способность

Доступность

Другие методы долгосрочной оценки, которые могут составлять договор или соглашение

Логика кодирования

Контентная логика

Сообщение и преобразование данных

Эффективность

посредник

Сопоставление идентификатора объекта

Сжатие данных

Предоставление услуг и регистрация

Запись, измерение и мониторинг

найти

Интеграция системного управления и инструментов управления

Самоконтроль и самоуправление

Объектное моделирование

Общее моделирование бизнес-объектов

Библиотека форматов данных

Интегрированная государственная и частная модель B2B

Инструменты разработки и развертывания

Бизнес правила

Поведение на основе политик, особенно для уровней обслуживания, безопасности и функций качества обслуживания (например, Политика веб-служб (WS-Policy))

Распознавание образов

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

Реализация ESB, поддерживающая минимальную функциональность SOA.

Если только некоторые из ранее идентифицированных функций имеют отношение к большинству сценариев SOA, мы можем спросить: что составляет минимальный набор функций, необходимых для реализации ESB? С этой целью рассмотрим наиболее общепризнанные принципы определений ESB:

ESB — это компонент логической архитектуры, который обеспечивает интегрированную инфраструктуру, соответствующую принципам SOA.

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

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

ESB предоставляет методы для управления сервисной инфраструктурой и функциями для работы в распределенной гетерогенной среде.

Самые низкие возможности ESB

Предоставлять услуги маршрутизации и адресации с прозрачностью местоположения

Функции управления, управляющие адресацией и именованием услуг

По крайней мере, одна форма парадигмы обмена сообщениями (например, запрос / ответ, публикация / подписка и т. Д.)

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

Поддержка нескольких методов интеграции, предоставляемых службами, таких как соединители Java 2, веб-службы, асинхронная связь, адаптеры и т. Д.

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

Обратите внимание, что эти минимальные функции не требуют использования специальных технологий, таких как промежуточное программное обеспечение EAI, веб-службы, J2EE или XML. Использование этих технологий очень близко и соответствует требованиям, но использовать их не обязательно. Напротив, минимальная функциональность может быть почти достигнута простым использованием SOAP / HTTP и WSDL (конечно, не во всех случаях):

URL-адресация и существующая инфраструктура HTTP и DNS обеспечивают «шину» со службами маршрутизации и прозрачностью местоположения.

SOAP / HTTP поддерживает спецификацию связи «запрос-ответ».

Протокол передачи HTTP широко используется.

SOAP и WSDL — это открытые, независимые от реализации модели взаимодействия и подключения служб.

Однако эти базовые приложения SOAP / HTTP и WSDL представляют собой только интеграцию точка-точка и не могут выполнять некоторые ключевые функции, требуемые ESB:

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

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

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

Функции качества и уровня обслуживания.

Расширенные концепции SOA, такие как оркестровка сервисов, каталог, преобразование и т. Д.

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

Поистине асинхронная операция в нескольких сетях, нескольких протоколах и нескольких доменах с разными владельцами.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: