Что такое ESB и для чего он хорош?

Question

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

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

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

Answer 1

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

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

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

Фактические реализации

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

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

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

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

Мэшапы

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

Все совершенно разные сервисы, несовместимые сами по себе, но используя стандартные соединители (например, трубы Yahoo), они могут быть объединены в единое и полезное целое.

-Adam

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

Это в основном концептуальный способ проектирования системы - компании-разработчики пытаются продать вам больше, наклеив на нее наклейку с надписью «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" цена = 101,4 vol = 100}) - обратите внимание, что пункт назначения вводится из ESB

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

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

• REST vs. SOAP
• неподтвержденный XML и XML, проверенный с помощью XSD
• Groovy vs. Java
• интерпретируемый язык против скомпилированного языка

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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