Что такое ESB и для чего это полезно?

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

Мэшапы

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

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

-Adam

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 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})

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

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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