Что такое ESB и для чего он нужен?

На предыдущей работе было много разговоров о «Enterprise Service Bus» (ESB). Я читал об этом отрывки из концептуальной книги, но никогда толком не понимал, как вы могли бы реализовать / интегрировать это в конкретных терминах. Я знаком с SOA / queuing / directory services / и т. Д. но я не понимаю, что такое ESB.

Это конкретная вещь (служба / сервер / брокер / и т. Д.), Которую вы просто подключаете к нему разными способами, или это больше просто концептуальный способ проектирования систем?

Будем очень признательны за любые объяснения или ссылки на хорошие примеры. Спасибо.

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

Это может включать посредничество для согласования несовместимых протоколов, данных и взаимодействия.

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

Актуальные реализации

Что касается фактических реализаций, это сфера деятельности очень крупных предприятий поддержки. Хотя это очень модно, цель - это идеал, который на каком-то небольшом уровне можно понять путем сравнения с Интернетом:

Сходство с Интернетом

Одна большая коммуникационная шина с самыми разными использованиями и данными, но все они используют стандартизированные протоколы.

Фактически, можно написать соединитель HTTP-FTP, который позволит браузерам получать доступ к FTP-сайтам без вызова FTP-клиента (обычно встроенного в браузер сейчас).

Мэшапы

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

Все совершенно разные сервисы, несовместимые сами по себе, но с помощью стандартных коннекторов (например, yahoo pipe) их можно объединить в единое и полезное целое.

-Адам

Отказ от ответственности: я работаю в IBM и консультирую по WebSphere ESB, продукту IBM, разработанному для создания ESB с. Ниже приведены мои мнения, которые не обязательно отражают позицию IBM.

К сожалению, ESB - это разные вещи для разных людей.

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

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

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

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

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

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

ESB - это, по сути, MOM (промежуточное программное обеспечение, ориентированное на сообщения) с добавленной моделью данных и управлением определением структуры. У вас есть общее определение данных для всех приложений и адаптеров на этой шине (может быть XML с общим XSD). Все, что подключается, ДОЛЖНО отправлять свою информацию в соответствии с этим определением данных. ESB поддерживает загрузку, совместное использование и управление версиями этого определения общих данных. При подключении нового компонента к ESB вы можете ожидать большей «совместимости» из коробки, чем при подключении его к MOM. Каждый компонент на этой шине концептуально рассматривается как «ресурс», поэтому для отделения отправителя от получателя вводится дополнительная абстракция.

Пример: допустим, вы хотите соединить приложение A с приложением B в стандартном промежуточном программном обеспечении, ориентированном на сообщения, возьмем JMS. Вы разговариваете со своими коллегами, работающими над приложением B, согласовываете тему, тип сообщения и поля и отправляете его (псевдокод): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101.4 vol = 100})

Если вы делаете то же самое в сервис-ориентированной архитектуре, вам необходимо

1. установить дополнительное программное обеспечение
2. узнать много новых концепций
3. определите свой новый компонент Java в интерфейсе администратора ESB
4. реализовать некоторые интерфейсы, которые контролируются ESB
5. sendJms (getDestination (), {MapMessage trader = "pete" price = 101.4 vol = 100}) - обратите внимание, что пункт назначения вводится из ESB

В первый раз это, наверное, немного болезненно, но я думаю, вы можете привыкнуть к этому, так же как вы можете привыкнуть к EJB ;-)

Можно сказать, что система MOM «нетипизирована» (динамическая структура), а ESB - «типизирована» (статическая структура). Компромиссы между необработанными сообщениями и ESB аналогичны другим нетипизированным / типизированным вариантам:

• ОТДЫХ против мыла
• непроверенный XML против XML, проверенного с помощью XSD
• Groovy против Java
• интерпретируемый язык против компилируемого языка

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

Так что, если ваш проект страдает от того, что слишком много людей ломают систему, регистрируя непроверенные изменения - переходите к большей структуре (ESB вместо MOM). Если ваши проекты страдают от того, что не выполняется достаточное количество задач вовремя - выберите более простое, нетипизированное решение. Если и то, и другое - найди консультанта (шучу ;-)

Ну, это зависит от того, кого вы спросите ... Многие скажут, что это часть «промежуточного программного обеспечения», которое соединяет вместе различные части «бизнес-логики», чтобы убрать кодировку из обмена сообщениями между этими модулями. Я думаю, что это достаточно общее определение, но я уверен, что вы уже получили его через Википедию и так далее.

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

Думаю, это настолько ясно, насколько я могу ... Надеюсь, это поможет.

Взгляните на мою презентацию « Избалованный выбором - как правильно выбрать ESB ».

Я объясняю, когда использовать ESB, Integration Suite или просто Integration Framework (например, Apache Camel). Я также обсуждаю различия между ESB с открытым исходным кодом и проприетарными.

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

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