Корпоративная сервисная шина ( 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]
ESB реализован в программном обеспечении, которое работает между бизнес-приложениями и обеспечивает связь между ними. В идеале ESB должен иметь возможность заменить все прямые контакты с приложениями на шине, так что вся связь происходит через ESB. Для достижения этой цели ESB должен инкапсулировать функциональность, предлагаемую его компонентными приложениями, осмысленным образом. Обычно это происходит с помощью модели корпоративных сообщений . Модель сообщений определяет стандартный набор сообщений, которые ESB передает и получает. Когда ESB получает сообщение, он направляет его соответствующему приложению. Часто, поскольку это приложение развивалось без той же модели сообщений, ESB должен преобразовать сообщение в формат, который приложение может интерпретировать. Программный адаптер выполняет задачу осуществления этих преобразований, аналогично физическому адаптеру . [ 5]
ESB полагаются на точное построение модели корпоративных сообщений и правильное проектирование функциональности, предлагаемой приложениями. Если модель сообщений не полностью инкапсулирует функциональность приложения, то другим приложениям, которым нужна эта функциональность, придется обходить шину и напрямую вызывать несоответствующие приложения. Это нарушает принципы модели ESB и сводит на нет многие преимущества использования этой архитектуры.
Прелесть ESB заключается в его платформенно-независимой природе и способности интегрироваться с чем угодно в любых условиях. Важно, чтобы поставщики Application Lifecycle Management действительно применяли все возможности ESB в своих интеграционных продуктах при принятии SOA . Таким образом, проблемы и возможности для поставщиков EAI заключаются в предоставлении интеграционного решения, которое является недорогим, легко настраиваемым, интуитивно понятным, удобным для пользователя и открытым для любых инструментов, которые выберут клиенты.
¹ Некоторые не считают хореографию процесса функцией ESB. Например, см. M.Richards. [6]
² В то время как хореография процессов поддерживает реализацию сложных бизнес-процессов, требующих координации нескольких бизнес- сервисов (обычно с использованием BPEL ), оркестровка сервисов позволяет координировать несколько сервисов внедрения (наиболее подходящим образом представленных в виде совокупного сервиса) для обслуживания отдельных запросов.
Эти решения часто фокусируются на низкоуровневых функциях ESB, таких как подключение, маршрутизация и преобразование, и требуют кодирования или написания сценариев для реализации оркестровки. [7] Разработчики, работающие на проектном или тактическом уровне, например, просто пытаясь решить проблему, часто тяготеют к облегченным технологиям сервисной шины, но часто существует постоянное напряжение между этими инициативами и корпоративной архитектурой, целью которой является оптимизация инфраструктуры в рамках нескольких проектов. [8]
Если брокер сообщений, программное обеспечение ESB, переводит сообщение из одного формата в другой, то, как и при любом переводе, возникает проблема семантики сообщения. Например, запись может быть переведена из JSON в XML, но один и тот же набор полей может быть интерпретирован по-разному разными приложениями, особенно в случае различных угловых случаев, которые обычно известны только разработчикам, имеющим большой опыт работы с приложением, подключенным к ESB. Для известных угловых случаев количество тестов, которые охватывают все угловые случаи, увеличивается экспоненциально с каждым приложением, подключенным к ESB, поскольку каждое приложение, подключенное к ESB, должно быть протестировано относительно каждого другого приложения, подключенного к ESB.
Среди известных продуктов:
Первое, что должен иметь в виду архитектор ESB, — это то, что по состоянию на 2010 год не существует глобального стандарта для ESB.
Я не считаю хореографию процессов частью ESB, если мы рассматриваем ESB как высокоскоростное промежуточное программное обеспечение обмена сообщениями. Однако я считаю хореографию процессов частью *платформы* ESB. К счастью, большинство поставщиков ESB выделяют эти основные компоненты в разные продукты, но упаковывают их в консолидированное предложение ESB. Так что, в самом строгом смысле этого слова, нет, я бы не считал это частью ESB. Это связанная возможность.