Що таке ESB і для чого він корисний?

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

Це конкретна річ (сервіс / сервер / брокер / тощо), що ви просто підключаєте до неї всі свої програми різними способами, чи це більше просто концептуальний спосіб проектування систем?

Будемо вдячні за будь-які пояснення чи посилання на хороші приклади. Дякую.

Це досить високий рівень концепції абстракції. Основна концепція полягає в тому, що 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 розглядається як панацея від усіх технічних проблем, якими він не є, занадто багато часу витрачається на шину, а не на програми / дані, які підключаються. Часто буває, що багато конкуруючих стандартів боротимуться за першість в одній і тій же організації, що призведе до класичних силосів, в яких переважають технології, і які ці системи насправді мають виправляти.

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

В основному це концептуальний спосіб розробити систему - компанії-виробники програмного забезпечення намагаються продати вам більше, наклеюючи на них наклейку "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 подібні до інших нетипізованих / типових варіантів:

• REST проти SOAP
• неперевірений XML проти XML, перевірений XSD
• Groovy проти Java
• інтерпретована мова проти компільованої мови

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

Отже, якщо ваш проект страждає від того, що занадто багато людей ламають систему, перевіряючи неправомірні зміни - рухайтесь до більшої структури (ESB замість MOM). Якщо ваші проекти страждають від того, що вчасно не виконано достатньо речей - виберіть більш просте, нетипізоване рішення. Якщо це обидва - зверніться до консультанта (жартую ;-)

Ну, це залежить від того, кого ви запитаєте ... Багато хто сказав би, що це частина "проміжного програмного забезпечення", яка з'єднує різні частини "бізнес-логіки", щоб вивести кодування з обміну повідомленнями між цими модулями. Я вважаю, що це досить загальне визначення, але я впевнений, що ви вже потрапили туди через Вікіпедію і не тільки.

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

Я думаю, це настільки зрозуміло, наскільки я можу бути ... Сподіваюся, це допомагає.

Погляньте на мою презентацію " Зіпсований вибір - як правильно вибрати ESB ".

Я пояснюю, коли використовувати ESB, Integration Suite або просто Integration Framework (наприклад, Apache Camel). Я також обговорюю відмінності між відкритими кодами та власними ESB.

Крім стандартного визначення, яке ви можете отримати з Вікіпедії . Я вважаю, що це чудовий інструмент для підключення низки застарілих систем між різними платформами та технологіями. Це також хороший інструмент для побудови розподілених робочих процесів та систем управління державою (таких як головна книга).

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