Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia.
Если в «дошинную» эпоху общепринятой концепцией была интеграция различных систем друг с другом напрямую, т.н. соединение «точка-точка», то с появлением шины — она становится главным транспортным узлом в интеграционной архитектуре предприятия, в определённом смысле объединяя в себе все API предприятия:
КСШ собой эволюционный виток архитектурной мысли в рамках сервисно-ориентированной архитектуры в «домикросервисную эпоху». Хорошо подходит для средних размеров предприятий с относительно небольшим количеством ИС (десятки).
Оглянувшись на свой и чужой опыт, можно извлечь несколько уроков использования КСШ:
- Заклинаю, не надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует только как транспорт.
Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки — нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock; - ESB могут стать «узким горлышком», когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей —> больше общий TTM (time to market).
Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, знающих Шину — стремится к нулю. - На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли «вешать» разработку и тестирование на вендора?
Автотесты требуют всегда актуальных артефактов п.4; - Должен быть выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех ИС, работающих с Шиной. Нужны Архитекторы, и они должны быть «пишущие».
В основном это касается крупных ESB, на которые «нацеплены» большая часть ИС предприятия.
Если мы говорим о «небольших» шинах типа Kafka и RabbitMQ, то с ними всё гораздо проще, кроме того, они часто задействованы в микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.
Видео:Плюсы и минусы сервисной шины данных I Enterprise service bus (ESB) I kt.teamСкачать
Сервисный автобус предприятия — Enterprise service bus
Сервисная шина предприятия ( ESB ) реализует систему связи между взаимно взаимодействующим программными приложениями в сервисе-ориентированной архитектуре (SOA). Он представляет программную архитектуру для распределенных вычислений и является особым вариантом более общей модели клиент-сервер , в которой любое приложение может вести себя как сервер или клиент. ESB обеспечивает маневренность и гибкость в отношении высокоуровневой протокольной связи между приложениями. Его основное применение — интеграция корпоративных приложений (EAI) разнородных и сложных сервисных ландшафтов.
Видео:DATAREON ESB. Коротко о главномСкачать
Архитектура
Концепция служебной шины предприятия аналогична концепции шины в архитектуре компьютерного оборудования в сочетании с модульной и параллельной конструкцией высокопроизводительных компьютерных операционных систем. Мотивация для разработки архитектуры заключалась в том, чтобы найти стандартную, структурированную и универсальную концепцию для описания реализации слабосвязанных программных компонентов (называемых службами ), которые, как ожидается, будут независимо развернуты, запущены, разнородны и разрознены в сети. ESB также является распространенным шаблоном реализации для сервис-ориентированной архитектуры , включая внутренне адаптированный сетевой дизайн Всемирной паутины .
Для концепций или реализаций служебной шины предприятия не существует глобальных стандартов. Большинство поставщиков промежуточного программного обеспечения, ориентированного на сообщения , приняли концепцию служебной шины предприятия как стандарт де-факто для сервис-ориентированной архитектуры. Реализации ESB используют управляемое событиями и основанное на стандартах промежуточное программное обеспечение, ориентированное на сообщения, в сочетании с очередями сообщений в качестве технологических структур. Однако некоторые производители программного обеспечения переименовывают существующее промежуточное программное обеспечение и коммуникационные решения как ESB, не принимая ключевой аспект концепции шины.
Функции
ESB применяет концепцию дизайна современных операционных систем к независимым службам, работающим в сетях разрозненных и независимых компьютеров. Подобно параллельным операционным системам, ESB предоставляет стандартные услуги в дополнение к принятию, трансляции и маршрутизации клиентских запросов к соответствующим службам ответа.
- Маршрутизация сообщений между службами
- Мониторинг и управление маршрутизацией обмена сообщениями между сервисами
- Разрешение разногласий между взаимодействующими сервисными компонентами
- Контроль развертывания и управления версиями сервисов
- Ограничьте использование избыточных сервисов
- Предоставлять стандартные услуги, такие как обработка событий, преобразование и сопоставление данных, постановка в очередь и последовательность сообщений и событий, безопасность или обработка исключений , преобразование протоколов и обеспечение надлежащего качества услуг связи.
Видео:Интеграционные шиныСкачать
История
Первое опубликованное использование термина «служебная шина предприятия» приписывается Рою В. Шульте из Gartner Group 2002 и книге Дэвида Чаппелла «Корпоративная служебная шина» . Хотя ряд компаний считают, что эта фраза была придумана, в интервью Шульте сказал, что впервые услышал эту фразу от компании Candle, и продолжил: «Самым прямым предком ESB был продукт Candle Roma. с 1998 », главным архитектором которого и держателем патентной заявки был Гэри Авен. Roma была впервые продана в 1998 году, что сделало ее первой коммерческой ESB на рынке, но продукт Sonic 2002 года также был одним из первых ESB на рынке.
- Служба — обозначает неитеративные и автономно выполняющиеся программы, которые взаимодействуют с другими службами посредством обмена сообщениями.
- Шина — используется по аналогии с аппаратной шиной компьютера.
- Предприятие — концепция изначально была изобретена для упрощения интеграции корпоративных приложений внутри предприятия; ограничение устарело, поскольку современное Интернет-общение больше не ограничивается юридическим лицом.
Читайте также: Материал для иммобилизирующей шины
ESB как программное обеспечение
ESB реализована в программном обеспечении, которое работает между бизнес-приложениями и обеспечивает связь между ними. В идеале ESB должна иметь возможность заменять все прямые контакты с приложениями на шине, чтобы все коммуникации происходили через ESB. Для достижения этой цели ESB должна инкапсулировать функциональные возможности, предлагаемые ее компонентными приложениями, значимым образом. Обычно это происходит за счет использования модели корпоративных сообщений . Модель сообщений определяет стандартный набор сообщений, которые передает и принимает ESB. Когда ESB получает сообщение, он направляет его в соответствующее приложение. Часто, поскольку это приложение развивалось без той же модели сообщения, ESB должна преобразовать сообщение в формат, который приложение может интерпретировать. Программный адаптер выполняет эти преобразования аналогично физическому адаптеру .
ESB полагаются на точное построение модели корпоративных сообщений и правильное проектирование функциональных возможностей, предлагаемых приложениями. Если модель сообщения не полностью инкапсулирует функциональные возможности приложения, то другим приложениям, которым нужна эта функциональность, возможно, придется обходить шину и напрямую вызывать несовпадающие приложения. Это нарушает принципы модели ESB и сводит на нет многие преимущества использования этой архитектуры.
Прелесть ESB заключается в ее независимости от платформы и способности интегрироваться с чем угодно в любых условиях. Важно, чтобы поставщики управления жизненным циклом приложений действительно применяли все возможности ESB в своих интеграционных продуктах при внедрении SOA . Следовательно, проблемы и возможности для поставщиков EAI заключаются в том, чтобы предоставить решение интеграции, которое было бы недорогим, легко настраиваемым, интуитивно понятным, удобным для пользователя и открытым для любых инструментов, которые выбирают клиенты.
Характеристики
| Категория | Функции |
|---|---|
| Призыв | поддержка синхронных и асинхронных транспортных протоколов, отображение сервисов (определение местоположения и привязка) |
| Маршрутизация | адресуемость, статическая / детерминированная маршрутизация, маршрутизация на основе содержимого, маршрутизация на основе правил, маршрутизация на основе политик |
| Посредничество | адаптеры, преобразование протоколов, отображение сервисов |
| Обмен сообщениями | обработка сообщений, преобразование сообщений и улучшение сообщений |
| Хореография процесса ¹ | реализация сложных бизнес-процессов |
| Сервисная оркестровка ² | координация нескольких услуг по внедрению, представленных как единая совокупная услуга |
| Обработка сложных событий | интерпретация событий, корреляция, сопоставление с образцом |
| Другое качество обслуживания | безопасность (шифрование и подпись), надежная доставка, управление транзакциями |
| Управление | мониторинг, аудит, ведение журнала, измерение, консоль администратора, BAM (BAM не является функцией управления, другими словами, ESB не реагирует на определенный порог. Это возможность бизнес-службы, доступная конечным пользователям). |
| Агностицизм | общий агностицизм по отношению к операционным системам и языкам программирования; например, она должна обеспечивать возможность взаимодействия между Java и .NET приложений |
| Преобразование протокола | комплексная поддержка актуальных стандартов обслуживания протоколов связи |
| Шаблоны обмена сообщениями | поддержка различных MEP ( шаблонов обмена сообщениями ) (например: синхронный запрос / ответ, асинхронный запрос / ответ, отправка и забытие, публикация / подписка) |
| Адаптеры | адаптеры для поддержки интеграции с устаревшими системами, возможно, на основе таких стандартов, как JCA |
| Безопасность | стандартизированная модель безопасности для авторизации, аутентификации и аудита использования ESB |
| Трансформация | облегчение преобразования форматов данных и значений, включая службы преобразования (часто через XSLT или XQuery ) между форматами приложения-отправителя и приложения-получателя |
| Проверка | проверка по схемам для отправки и получения сообщений |
| Управление | возможность единообразного применения бизнес-правил |
| Обогащение | обогащение сообщений из других источников |
| Разделить и объединить | разделение и объединение нескольких сообщений и обработка исключений |
| Абстракция | предоставление единой абстракции на нескольких уровнях |
| Маршрутизация и преобразование | условная маршрутизация или преобразование сообщений на основе нецентрализованной политики (без необходимости в центральной системе правил) |
| Товарные Услуги | предоставление часто используемых функций в качестве общих служб в зависимости от контекста |
¹ Некоторые не считают хореографию процесса функцией ESB. Например, см. М. Ричардс.
² В то время как хореография процессов поддерживает реализацию сложных бизнес-процессов, требующих координации нескольких бизнес- сервисов (обычно с использованием BPEL ), оркестровка сервисов позволяет координировать множественные сервисы реализации (наиболее подходящие для представления как агрегированные сервисы) для обслуживания отдельных запросов.
Эти решения часто ориентированы на низкоуровневые функции ESB, такие как подключение, маршрутизация и преобразование, и требуют кодирования или написания сценариев для реализации оркестровки. Разработчики, работающие на проектном или тактическом уровне, например, просто пытаясь решить проблему, часто тяготеют к упрощенным технологиям служебной шины, но часто существует постоянное противоречие между этими инициативами и архитектурой предприятия, целью которой является оптимизация инфраструктуры для нескольких проектов.
Если брокер сообщений, программное обеспечение ESB, переводит сообщение из одного формата в другой, то, как и при любом переводе, возникает проблема семантики сообщения. Например, запись может быть преобразована из JSON в XML, но один и тот же набор полей может по-разному интерпретироваться разными приложениями, особенно в случае различных угловых случаев, которые обычно известны только разработчикам, имеющим большой опыт работы с приложением. который подключен к ESB. Для известных угловых случаев количество тестов, охватывающих все угловые случаи, увеличивается экспоненциально с каждым приложением, подключенным к ESB, потому что каждое приложение, подключенное к ESB, должно быть протестировано против всех других приложений, подключенных к 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
- Свежие записи
- Нужно ли менять пружины при замене амортизаторов
- Скрипят амортизаторы на машине что делать
- Из чего состоит стойка амортизатора передняя
- Чем стянуть пружину амортизатора без стяжек
- Для чего нужны амортизаторы в автомобиле
💡 Видео
СПРОСИ ЭКСПЕРТА: Выпуск 1. Чем отличается шина данных от ETL?Скачать
Интеграция систем 1С с помощью сервисной шины предприятия DATAREON ESBСкачать
Вебинар "InterSystems IRIS как сервисная шина предприятия (Enterprise Service Bus)"Скачать
Интеграция систем на примере шины ESB · Евгений Путилин · ЛАФ #системныйаналитикСкачать
Интеграционная шина предприятия. Правило импорта.Скачать
Корпоративная сервисная шина данных DATAREON ESB. Знакомство с продуктом. Урок 1Скачать
Интеграционная шина - обмен данными между подразделениями предприятияСкачать
Корпоративная сервисная шина данных DATAREON ESB. Знакомство с объектами ESB. Урок 2Скачать
Корпоративная сервисная шина DATAREON ESB. Назначение классов и маршрутов передачи данных. Урок 4Скачать
Корпоративная сервисная шина данных DATAREON ESB. Взаимодействие с 1С. Урок 5Скачать
Шины данных и интеграции | ESB шина данных | Интеграция 1С ERPСкачать
Установка и настройка шины DATAREON ESBСкачать
Сравнение ESB-систем | Ключевые отличия от брокеров сообщений | kt.teamСкачать
DATAREON ESB (сервисная шина данных) (Вебинар 02.02.2016)Скачать
