Корпоративная сервисная шина

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

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

Архитектура

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

Не существует глобальных стандартов для концепций или реализаций корпоративных сервисных шин. ^[1] Большинство поставщиков промежуточного программного обеспечения, ориентированного на сообщения, приняли концепцию корпоративной сервисной шины в качестве фактического стандарта для сервис-ориентированной архитектуры. Реализации ESB используют управляемое событиями и стандартами промежуточное программное обеспечение, ориентированное на сообщения, в сочетании с очередями сообщений в качестве технологических инфраструктур. ^[2] Однако некоторые производители программного обеспечения переименовывают существующее промежуточное программное обеспечение и коммуникационные решения в ESB, не принимая при этом решающий аспект концепции шины.

Функции

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

Основными обязанностями ESB являются:

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

История

Первое опубликованное использование термина «корпоративная сервисная шина» приписывается Рою В. Шульте из Gartner Group в 2002 году и книге «Корпоративная сервисная шина» Дэвида Чаппелла . Хотя авторство этой фразы принадлежит ряду компаний, в интервью Шульте сказал, что впервые он услышал эту фразу от компании Candle, и далее сказал: «Самым прямым предком ESB был продукт Roma компании Candle. с 1998 года" ^[3] чьим главным архитектором и обладателем патентной заявки был Гэри Авен. Впервые Roma был продан в 1998 году, что сделало его первым коммерческим ESB на рынке, но продукт Sonic 2002 года также был одним из первых ESB на рынке. ^[4]

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

ESB как программное обеспечение

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

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

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

Характеристики

Категория	Функции
Призыв	поддержка синхронных и асинхронных транспортных протоколов, сопоставление сервисов (поиск и привязка)
Маршрутизация	адресность, статическая/детерминированная маршрутизация, маршрутизация на основе контента, маршрутизация на основе правил, маршрутизация на основе политик
Посредничество	адаптеры, преобразование протоколов, отображение сервисов
Обмен сообщениями	обработка сообщений, преобразование сообщений и улучшение сообщений
Хореография процесса ¹	реализация сложных бизнес-процессов
Оркестрация служб ²	координация нескольких служб внедрения, представленных как единая совокупная услуга
Сложная обработка событий	интерпретация событий, корреляция, сопоставление с образцом
Другое качество обслуживания	безопасность (шифрование и подпись), надежная доставка, управление транзакциями
Управление	мониторинг, аудит, ведение журнала, измерение, консоль администратора, BAM (BAM не является функцией управления, другими словами, ESB не реагирует на определенный порог. Это возможность бизнес-службы, предоставляемая конечным пользователям.)
Агностицизм	общий агностицизм в отношении операционных систем и языков программирования; например, он должен обеспечить совместимость между Java и .NET. приложениями
Преобразование протокола	комплексная поддержка актуальных стандартов обслуживания протоколов связи
Шаблоны обмена сообщениями	поддержка различных MEP ( шаблоны обмена сообщениями ) (например: синхронный запрос/ответ, асинхронный запрос/ответ, «отправить и забыть», опубликовать/подписаться)
Адаптеры	адаптеры для поддержки интеграции с устаревшими системами, возможно, на основе таких стандартов, как JCA
Безопасность	стандартизированная модель безопасности для авторизации, аутентификации и аудита использования ESB
Трансформация	облегчение преобразования форматов и значений данных, включая услуги преобразования (часто через XSLT или XQuery ) между форматами отправляющего приложения и принимающего приложения
Валидация	проверка на соответствие схемам отправки и получения сообщений
Управление	способность единообразно применять бизнес-правила
Обогащение	обогащение сообщений из других источников
Разделить и объединить	разделение и объединение нескольких сообщений и обработка исключений
Абстракция	предоставление единой абстракции на нескольких уровнях
Маршрутизация и преобразование	условная маршрутизация или преобразование сообщений на основе нецентрализованной политики (без необходимости использования центрального механизма правил)
Товарные услуги	предоставление часто используемых функций в качестве общих сервисов в зависимости от контекста

¹ Некоторые не считают хореографию процесса функцией ESB. Например, см. М.Ричардс. ^[6]

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

Эти решения часто фокусируются на низкоуровневых функциях ESB, таких как подключение, маршрутизация и преобразование, и требуют написания кода или сценариев для реализации оркестрации. ^[7] Разработчики, работающие на проектном или тактическом уровне, например, просто пытающиеся решить проблему, часто тяготеют к облегченным технологиям сервисной шины, но между этими инициативами и корпоративной архитектурой, целью которой является оптимизация инфраструктуры в нескольких проектах, часто существует постоянное противоречие. ^[8]

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

Ключевые преимущества

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

Основные недостатки

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

Продукты

Известные продукты включают:

Собственный
- Candle's Roma ESB - куплен IBM и стал WebSphere ESB.
- IBM App Connect, ранее IBM Integration Bus и IBM WebSphere ESB
- ИнтерСистемс Ансамбль
- Информационные строители Менеджер по обслуживанию iWay
- Microsoft Azure Служебная шина
- Microsoft BizTalk-сервер
- Мул ЭСБ
- Корпоративная сервисная шина Oracle
- Progress Software Sonic ESB (приобретена Trilogy )
- Интеграция процессов SAP
- Программное обеспечение TIBCO ActiveMatrix BusinessWorks
- Корпоративная сервисная шина webMethods (приобретена Software AG )
- Sonic ESB от Aurea
- XIATech Единый просмотр данных
Программное обеспечение с открытым исходным кодом
- Апач Верблюд
- Apache СервисМикс
- Апач-синапс
- Предохранитель ESB от Red Hat
- ДжейБосс ЭСБ
- NetKernel
- Открыть ESB
- Лепестки ЭСБ
- Весенняя интеграция
- УльтраЕС
- WSO2 ЕС
- Поэтому (и Python)

См. также

Ссылки

^ Лапейра, Рауль. «ESB — это архитектурный стиль, программный продукт или группа программных продуктов?» . Консультация по артефактам. Архивировано из оригинала 8 августа 2014 г. Проверено 16 апреля 2010 г. Первое, что должен иметь в виду архитектор ESB, это то, что по состоянию на 2010 год не существует глобального стандарта для ESB.
^ Карри, Эдвард. 2004. «Промежуточное программное обеспечение, ориентированное на сообщения». ^{[ постоянная мертвая ссылка ]}. В книге «Промежуточное программное обеспечение для коммуникаций» , под ред. Кусай Х. Махмуд, 1–28. Чичестер, Англия: Джон Уайли и сыновья. два : 10.1002/0470862084.ch1 . ISBN 978-0-470-86206-3
^ Маккендрик, Джо. «Великая ссора в ESB 2005 года» . ЗДНет . Проверено 31 декабря 2020 г.
^ «Разница между брокером сообщений и ESB» . Проверено 19 июля 2017 г.
^ «Корпоративный сервисный автобус [Книга]» .
^ Ричардс, Марк. «Роль Enterprise Service Bus (презентация)» . Проверено 4 июня 2009 г. Я не считаю хореографию процессов частью ESB, если рассматривать ESB как промежуточное программное обеспечение для высокоскоростного обмена сообщениями. Тем не менее, я считаю хореографию процесса частью *платформы* ESB. К счастью, большинство поставщиков ESB разделяют эти основные компоненты на разные продукты, но объединяют их в единое предложение ESB. Так что, в строгом смысле слова, нет, я бы не рассматривал это как часть ESB. Это связанная возможность.
^ Ферага, Матиас (6 июня 2011 г.). «Как: выбор между легкими и традиционными ESB» . Окто . Проверено 23 апреля 2014 г.
^ Фултон, Ларри (12 сентября 2007 г.). «Узнайте, как использовать облегченные ESB» . ФО2014. Архивировано из оригинала 27 января 2022 года . Проверено 23 апреля 2014 г.

Дальнейшее чтение

Дэвид Чаппелл, «Корпоративный служебный автобус» (О'Рейли: июнь 2004 г., ISBN 0-596-00675-6 )
Бинильдас А. Кристудас, «Сервис-ориентированная бизнес-интеграция Java» (Packt Publishers: февраль 2008 г., ISBN 1-84719-440-0 ; ISBN 978-1-84719-440-4 )
Майкл Белл, «Сервис-ориентированное моделирование: анализ услуг, проектирование и архитектура» (2008 Wiley & Sons, ISBN 978-0-470-14111-3 )

Внешние ссылки

«Прочная концепция или последнее модное словечко?» (Николя Фарж, 2003 г.)
Корпоративные служебные автобусы отправляются в путь: Испытательный центр Infoworld (22 июля 2005 г.)
JSR-208: Бизнес-интеграция Java (август 2005 г.)
Роль корпоративной сервисной шины (InfoQ – видеопрезентация) (23 октября 2006 г.)
Обзор ESB, часть первая: Определение ESB (InfoQ) (13 июля 2006 г.)
Обзор ESB, часть вторая: варианты использования (InfoQ) (5 июля 2006 г.)
«Служебная фабрика — прекрасная фабрика для систем новой эры» (Бинильдас А. Кристудас, 2007 г.)
«ESB в 2007 году: переход от шины с открытым исходным кодом к SOA» (Деннис Байрон, 20 сентября 2007 г.)
Агрегированные услуги в ServiceMix JBI ESB: PACKT Publishers (Бинильдас А. Кристудас, 30 ноября 2007 г.)
Альтернативы топологии ESB (InfoQ, А. Луи, 23 мая 2008 г.)
Переосмысление ESB: создание простой, безопасной и масштабируемой сервисной шины с помощью SOA-шлюза (Computerworld, Дж. Райан, 2011 г.)
Луи, Адриан; Марк Дюту (2 июля 2010 г.). «Выбор между маршрутизацией и оркестровкой в ESB» . ИнфоQ . Проверено 2 июля 2009 г.
Пересмотр Enterprise Service Bus (разработчик IBM Works, Грег Фларри и Ким Кларк, май 2011 г.)

[1] Лапейра, Рауль. «ESB — это архитектурный стиль, программный продукт или группа программных продуктов?» . Консультация по артефактам. Архивировано из оригинала 8 августа 2014 г. Проверено 16 апреля 2010 г. Первое, что должен иметь в виду архитектор ESB, это то, что по состоянию на 2010 год не существует глобального стандарта для ESB.

[2] Карри, Эдвард. 2004. «Промежуточное программное обеспечение, ориентированное на сообщения». ^{[ постоянная мертвая ссылка ]}. В книге «Промежуточное программное обеспечение для коммуникаций» , под ред. Кусай Х. Махмуд, 1–28. Чичестер, Англия: Джон Уайли и сыновья. два : 10.1002/0470862084.ch1 . ISBN 978-0-470-86206-3

[3] Маккендрик, Джо. «Великая ссора в ESB 2005 года» . ЗДНет . Проверено 31 декабря 2020 г.

[4] «Разница между брокером сообщений и ESB» . Проверено 19 июля 2017 г.

[5] «Корпоративный сервисный автобус [Книга]» .

[6] Ричардс, Марк. «Роль Enterprise Service Bus (презентация)» . Проверено 4 июня 2009 г. Я не считаю хореографию процессов частью ESB, если рассматривать ESB как промежуточное программное обеспечение для высокоскоростного обмена сообщениями. Тем не менее, я считаю хореографию процесса частью *платформы* ESB. К счастью, большинство поставщиков ESB разделяют эти основные компоненты на разные продукты, но объединяют их в единое предложение ESB. Так что, в строгом смысле слова, нет, я бы не рассматривал это как часть ESB. Это связанная возможность.

[7] Ферага, Матиас (6 июня 2011 г.). «Как: выбор между легкими и традиционными ESB» . Окто . Проверено 23 апреля 2014 г.

[8] Фултон, Ларри (12 сентября 2007 г.). «Узнайте, как использовать облегченные ESB» . ФО2014. Архивировано из оригинала 27 января 2022 года . Проверено 23 апреля 2014 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]