Сервисная шина предприятия ( ESB ) реализует систему связи между взаимно взаимодействующим программными приложениями в сервисе-ориентированной архитектуре (SOA). Он представляет программную архитектуру для распределенных вычислений и является особым вариантом более общей модели клиент-сервер , в которой любое приложение может вести себя как сервер или клиент. ESB обеспечивает маневренность и гибкость в отношении высокоуровневой протокольной связи между приложениями. Его основное применение - интеграция корпоративных приложений (EAI) разнородных и сложных сервисных ландшафтов.
Архитектура [ править ]
Концепция служебной шины предприятия аналогична концепции шины в архитектуре компьютерного оборудования в сочетании с модульной и параллельной конструкцией высокопроизводительных компьютерных операционных систем. Мотивация для разработки архитектуры заключалась в том, чтобы найти стандартную, структурированную и универсальную концепцию для описания реализации слабосвязанных программных компонентов (называемых службами ), которые, как ожидается, будут независимо развернуты, запущены, разнородны и разрознены в сети. ESB также является распространенным шаблоном реализации для сервис-ориентированной архитектуры , включая внутренне адаптированный сетевой дизайн Всемирной паутины .
Для концепций или реализаций служебной шины предприятия не существует глобальных стандартов. [1] Большинство поставщиков промежуточного программного обеспечения, ориентированного на сообщения , приняли концепцию служебной шины предприятия как стандарт де-факто для ориентированной на службы архитектуры. Реализации ESB используют управляемое событиями и основанное на стандартах промежуточное программное обеспечение, ориентированное на сообщения, в сочетании с очередями сообщений в качестве технологических структур. [2] Однако некоторые производители программного обеспечения переименовывают существующее промежуточное программное обеспечение и коммуникационные решения как ESB, не принимая ключевой аспект концепции шины.
Функции [ править ]
ESB применяет концепцию дизайна современных операционных систем к независимым службам, работающим в сетях разрозненных и независимых компьютеров. Подобно параллельным операционным системам, ESB предоставляет стандартные услуги в дополнение к принятию, трансляции и маршрутизации клиентских запросов к соответствующим службам ответа.
Основные обязанности ESB:
- Маршрутизация сообщений между службами
- Мониторинг и управление маршрутизацией обмена сообщениями между сервисами
- Разрешение разногласий между взаимодействующими сервисными компонентами
- Контроль развертывания и управления версиями сервисов
- Ограничьте использование избыточных сервисов
- Предоставлять стандартные услуги, такие как обработка событий, преобразование и сопоставление данных, постановка в очередь и последовательность сообщений и событий, безопасность или обработка исключений , преобразование протоколов и обеспечение надлежащего качества услуг связи.
История [ править ]
Первое опубликованное использование термина «служебная шина предприятия» приписывается Рою В. Шульте из Gartner Group 2002 и книге Дэвида Чаппелла «Корпоративная служебная шина» . Хотя ряд компаний считают, что эта фраза была придумана, в интервью Шульте сказал, что впервые услышал эту фразу от компании Candle, и продолжил: «Самым прямым предком ESB был продукт Candle Roma. с 1998 г. » [3] , главным архитектором которого и держателем патентной заявки был Гэри Авен. Roma была впервые продана в 1998 году, что сделало ее первой коммерческой ESB на рынке, но продукт Sonic 2002 года также был одним из первых ESB на рынке. [4]
- Служба - обозначает неитеративные и автономно выполняющиеся программы, которые взаимодействуют с другими службами посредством обмена сообщениями.
- Шина - используется по аналогии с аппаратной шиной компьютера.
- Предприятие - концепция изначально была изобретена для упрощения интеграции корпоративных приложений внутри предприятия; ограничение устарело, поскольку современное Интернет-общение больше не ограничивается юридическим лицом.
ESB как программное обеспечение [ править ]
 | В этом разделе не процитировать любые источники . ( Октябрь 2014 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
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
- Ансамбль InterSystems
- Информационные конструкторы iWay Service Manager
- Сервисная шина Microsoft Azure
- Microsoft BizTalk Server
- Мул ESB
- Сервисная шина Oracle Enterprise
- Progress Software Sonic ESB (приобретена Trilogy )
- Интеграция процессов SAP
- Программное обеспечение TIBCO ActiveMatrix BusinessWorks
- служебная шина предприятия webMethods (приобретена Software AG )
- Sonic ESB от Aurea
- Программное обеспечение с открытым исходным кодом
- Apache Camel
- Apache ServiceMix
- Apache Synapse
- Предохранитель ESB от Red Hat
- JBoss ESB
- NetKernel
- Откройте ESB
- Лепестки ESB
- Интеграция Spring
- UltraESB
- WSO2 ESB
См. Также [ править ]
- Шаблоны корпоративной интеграции
- Обмен сообщениями, управляемыми событиями
- Бизнес-интеграция с Java
- управление бизнес-процессами
- Универсальная интеграционная платформа
- Интеграция корпоративных приложений
- Поставщик бизнес-услуг
- По промежуточного слоя, ориентированного на сообщения
- Обработка сложных событий
- Обработка потока событий
- Событийно-ориентированное программирование
- Сравнение программного обеспечения для бизнес-интеграции
- Сравнение двигателей BPEL
- Сравнение двигателей BPMN 2.0
- Составное приложение
- SOA, управляемая событиями
- Платформа интеграции как услуга (iPaaS)
Ссылки [ править ]
- ^ Лапейра, Рауль. «ESB - это архитектурный стиль, программный продукт или группа программных продуктов?» . Консультации по Артефактам. Архивировано из оригинала на 2014-08-08 . Проверено 16 апреля 2010 .
Первое, что должен иметь в виду архитектор ESB, это то, что по состоянию на 2010 год не существует глобального стандарта для ESB.
- ^ Карри, Эдвард. 2004. «Посредник, ориентированный на сообщения» [ постоянная мертвая ссылка ] . В промежуточном программном обеспечении для коммуникаций , под ред. Кусай Х. Махмуд, 1-28. Чичестер, Англия: Джон Уайли и сыновья. DOI : 10.1002 / 0470862084.ch1 . ISBN 978-0-470-86206-3
- ^ Маккендрик, Джо. «Великая ссора с ESB 2005 года» . ZDNet . Проверено 31 декабря 2020 .
- ^ «Разница между брокером сообщений и ESB» . Проверено 19 июля 2017 .
- ^ http://shop.oreilly.com/product/9780596006754.do
- ^ Ричардс, Марк. «Роль служебной шины предприятия (презентация)» . Проверено 4 июня 2009 .
Я не считаю хореографию процессов частью ESB, если мы рассматриваем ESB как промежуточное ПО для высокоскоростного обмена сообщениями.
Однако я считаю хореографию процессов частью платформы ESB * *.
К счастью, большинство поставщиков ESB разделяют эти основные компоненты на разные продукты, но объединяют их в единое предложение ESB.
Так что, в самом строгом смысле этого слова, нет, я бы не стал рассматривать это как часть ESB.
Это связанная возможность.
- ^ Feraga, Матиас (6 июня 2011). «Как: выбирать между легкими и традиционными ESB» . Octo . Проверено 23 апреля 2014 года .
- ↑ Фултон, Ларри (12 сентября 2007 г.). «Узнайте, как использовать легкие ESB» . Fo2014.
Дальнейшее чтение [ править ]
- Дэвид Чаппелл, "Enterprise Service Bus" (O'Reilly: июнь 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, A. Louis, 23 мая 2008 г.)
- Переосмысление ESB: создание простой, безопасной, масштабируемой служебной шины с помощью шлюза SOA (Computerworld, Дж. Райан, 2011 г.)
- Луи, Адриан; Марк Дуто (2010-07-02). «Выбор между маршрутизацией и оркестровкой в ESB» . InfoQ . Проверено 2 июля 2009 .
- Корпоративная служебная шина, пересмотренная (IBM Developer Works, Грег Флурри и Ким Кларк, май 2011 г.)
