Что такое ESB и для чего он хорош?
На предыдущей работе было много разговоров о "Enterprise Service Bus" (ESB). Я читал части концептуальной книги об этом, но так и не понял, как бы вы реализовали / интегрировали ее в конкретных терминах. Я знаком с SOA/ очередями / службами каталогов / и т.д. но я не понимаю, что такое ESB.
Это конкретная вещь (сервис / сервер / брокер / и т. Д.), Что вы просто подключаете все свои приложения к нему по-разному, или это скорее просто концептуальный способ проектирования систем?
Любые объяснения или ссылки на хорошие примеры будут с благодарностью. Благодарю.
7 ответов
Это довольно высокий уровень абстракции. Основная идея заключается в том, что ESB предоставляет промежуточное программное обеспечение и интерфейсы, которые позволяют предприятиям подключать свои приложения без написания кода.
Это может включать посредничество для согласования несовместимых протоколов, данных и взаимодействия.
Идея центральной шины, на которой все проходит, дает возможность для дополнительных уровней абстракции. Использование отраслевых стандартов для "подключения" к этой шине других приложений, клиентов и т. Д. Делает так, что подключение новых услуг, источников данных, клиентов с различными потребностями является относительно простым.
Актуальные реализации
Что касается реальных реализаций, то это область очень крупных предприятий поддержки предприятий. Хотя это очень модно, цель - это идеал, который на небольшом уровне можно понять по сравнению с Интернетом:
Сходство с интернетом
Одна большая коммуникационная шина с различными типами использования и данными, но все они работают по стандартным протоколам.
Фактически можно написать соединитель HTTP-FTP, который позволил бы браузерам получать доступ к FTP-сайтам без вызова FTP-клиента (обычно встроенного в браузер сейчас).
Мэшапы
Mashups демонстрирует интересную реализацию - возьмите некоторые данные автобусных маршрутов у властей Сан-Франциско, сопоставьте их с Google, и расположите суши-бары от Yahoo с рейтингами и выполните простой запрос, который даст вам ближайший суши-бар, взвесив его так, чтобы вы были готов путешествовать немного дальше для лучшего бара.
Все совершенно разные сервисы, несовместимые сами по себе, но используя стандартные соединители (например, трубы Yahoo), они могут быть объединены в единое и полезное целое.
-Адам
Отказ от ответственности: я работаю в 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})
Если вы делаете то же самое в сервис-ориентированной архитектуре, вам необходимо
- установить дополнительное программное обеспечение
- выучить много новых концепций
- определите свой новый компонент Java в интерфейсе администратора ESB
- реализовать некоторые интерфейсы, которые контролируются ESB
- 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 или просто интеграционную платформу (например, Apache Camel). Я также обсуждаю различия между открытыми и проприетарными ESB.