Різниця між брокером повідомлень та ESB

Я переглянув різні запитання / статті про брокерів повідомлень та ESB (навіть про stackoverflow). Все ще не є поняттям, як ЧИСЛО розмежовує різницю між брокером повідомлень та ESB? Зараз тут я намагаюся порівняти продукти, Websphere Broker та Mule ESB !!

По-перше, чи (будь-яка версія) Webshere Broker є ESB? Наші хлопці продуктів IBM стверджують, що це ESB! (Я не здивований з цього приводу).

Моя обмежена інформація говорить про те, що Брокер повідомлень працює на моделі HUB-SPOKE. Однак ESB працює над архітектурою шини. Що тепер на Землі це має означати? Я прочитав, ніж якщо HUB виходить з ладу (я думаю, недоступний), тоді брокер повністю виходить з ладу. Що не стосується ССВ (Так кажуть ці хлопці). Я не розумію тут "Що робити, якщо АВТОБУС" не працює?

Зараз звичайними речами про ESB та брокери є те, що вони забезпечують маршрутизацію, перетворення, оркестрацію тощо. Отже, якщо обидва вони надають це, то чому б я вибрав один за іншим.

Інша область конфлікту стосується перетворення. Чи полегшують це ESB по-різному в порівнянні з брокерами повідомлень? Я б дуже хотів трохи зрозуміти це.

Зараз говоримо про ГОРИЗОНТАЛЬНЕ масштабування. Хто перевершує кого? Або обидва вони однаково масштабовані за складністю (або будь-якими іншими факторами). Звичайно, варто розумно, Webshpere Broker стягне плату за кожну коробку (не кажучи вже про кожен процесор). Я вірю, що навіть комерційний MULE ESB цього не робить. Залишаючи осторонь її частину вартості, які наслідки мають масштабування ESB та масштабування повідомлень брокера. Я випадково знаю, що ви можете досягти рівня обслуговування в ESB. Це можливо в брокері повідомлень?

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

Брокер може мати вбудовані "блоки лего" для побудови ланцюга трансформації, ніж це має продукт ESB. Брокер, натиснутий на службу як ESB, може бути зруйнований під навантаженням і не мати масштабних масштабів, або може бракувати надійних журналів та інструментів для роботи з журналами.

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

Відмова: Я консультант IBM і спеціалізуюся на WebSphere ESB. Цей коментар не залишається в офіційній якості.

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

IBM, безумовно, продає як WebSphere Message Broker, так і WebSphere ESB як продукти, що полегшують побудову ESB (разом із апаратним пристроєм DataPower). Вони мають різні технологічні корені, але мають певне перекриття за призначенням. Крім того, це не означає, що ви не можете створити ESB з багатьма іншими речами, які не називаються "продуктом ESB".

Це не відповідає на всі ваші запитання, але, сподіваємось, стосується частини IBM.

Різниця між брокером повідомлень та ESB (Enterprise Service Bus) - головним чином слово "шина".

Для мене, Message Broker - це один (в основному великий) процес, який перетворює дані з однієї структури в іншу структуру або змінює контент.

ESB - це програмне забезпечення, орієнтоване на повідомлення (MOM), а також додаткові послуги, однією з яких може бути Брокер повідомлень. Таким чином, ESB може включати брокера повідомлень як один із його компонентів. Шина складається з декількох процесів, інакше я б не назвав це «шиною». Характер шини полягає в тому, що існує декілька компонентів, які виконують різні завдання, кожен з яких спілкується через MOM і дотримується певної форми "загального формату даних". Шина складається з: додатків, що надсилають дані в MOM, адаптери бази даних, брокери повідомлень, мости MOM тощо.

Поділ трохи поступовий, але найбільша відмінність між архітектурою Message Broker та шиною полягає в детальності . Якщо ваше завдання - інтегрувати програми A, B, .., Z та пару баз даних, ви можете зробити це за допомогою одного великого брокера повідомлень, що з'єднує кожного та кожного. Або з ESB, де кілька невеликих компонентів беруть на себе лише невеликі завдання. Наприклад, один адаптер підключається до A, інший - до B (але вони не здійснюють перетворення), потім кожен надсилає свої речі одному (або більше) брокерам повідомлень, кожен з яких повинен зберігатися максимально просто - наприклад, не знати про модель даних "A" або "B". Хороший ESB повинен мати загальне визначення даних на шині, абстрагуючись від «відмінності» окремих застосунків.

ТРАНСФОРМАЦІЯ: ESB не допомагає в трансформації, якщо він не постачається з брокером повідомлень. Але кожен хороший ESB все-таки повинен включати брокера повідомлень. Брокер повідомлень повинен бути експертом вашого автобуса для перетворень, але нічого іншого.

ГОРИЗОНТАЛЬНЕ масштабування: якщо у вас є лише 3 речі для підключення (зараз і назавжди), напевно, не варто докладати зусиль, щоб отримати повноцінний ESB. Брокер повідомлень має перевагу в тому, що це лише один великий процес. Ви можете налаштувати все, що там, і мати центральне місце для всіх ваших відображень даних, фільтрування та маршрутизації.

Але якщо у вас є 30 додатків для підключення, один Брокер повідомлень, ймовірно, прийде до зупинки. Звичайно, ви можете придбати більше примірників, запускати зайві речі тощо, але вам слід змінити стратегію, щоб "локалізувати" роботу. Кожен адаптер програми (може бути один маленький екземпляр брокера повідомлень) повинен мати можливість генерувати та / або отримувати абстраговану загальну модель даних (наприклад, XML із загальним XSD). Також може бути центральний брокер повідомлень для завдань трансформації, але цей екземпляр не повинен знати про модель даних A або B. Отже, ESB повинен перемістити обробку на експертний компонент, а не тримати все в центральному місці.

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

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

Цитування:

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

...

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

Без цього обмеження помилки просто занадто легко зробити.

Сподіваюся, це допомагає.

Enterprise Service Bus надає три ключові значення для бізнесу:

1. Контекстна або контентна маршрутизація транзакцій;
2. Перетворення з одного домену повідомлення або транспорту до іншого домену повідомлення або транспорту;
3. підключення до багатьох служб.

ESB надають слабке з'єднання послуг, дозволяють реконструювати служби у зовсім інші контексти прикладних програм, ніж тоді, коли послуги були вперше передбачені або розроблені, і сприяють повторному використанню програм без необхідності перекодувати додатки. WebSphere Message Broker (або зараз його називають шиною інтеграції IBM) - це яскравий приклад шини Enterprise Service. Для прикладу простоти коду, який приносить велику силу в декількох рядках, ви можете переглянути мою публікацію тут: http://soabus.org/viewtopic.php?f=3&t=13 . Фундаментальна конструкція всередині виконання IIB називається деревом логічного повідомлення(ЛМТ). Все, що розробник хоче зробити - це певний тип операцій на LMT. ESQL - це найефективніша мова, яку розробник може використовувати для виконання цих операцій на LMT, хоча підтримуються багато інших мов (наприклад, Java, PHP, Python тощо). Жоден інший продукт не наближається до ефективності та простоти розробки ESB програм, ніж IBM Integration Bus, оскільки 90 відсотків кодування цих додатків здійснюється шляхом перетягування вузлів на піддон. Це залишає лише 10 відсотків кодування, яке має зробити розробник Flow Flow. До речі, WebSphere ESB було припинено IBM, і багато конкуруючих продуктів в IBM Integration Bus вже кілька років не бачать нових розробок на них. Перелік різних пропозицій продуктів ESB можна переглянути на soabus.org.

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

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

ESB і Broker Broker - це синоніми один до одного, однак, як одна з відповідей вище, підкреслюється, що шаблон Messenger Broker є частиною більшого домену ESB. Буква "B" в ESB аналогічна шині (апаратному забезпеченню) в архітектурі комп'ютера. Шина на материнській платі або в комп'ютері з'єднує різні компоненти для функціонування комп'ютера. ESB - це програмна шина, що з'єднує різні послуги на підприємстві. Хаб і розмовляння - це одна з моделей, підтримуваних архітектурою ESB. У монолітному світі кожен постачальник має власну архітектуру розгортання, що забезпечує високу доступність, щоб забезпечити доступність ESB. Нещодавні пропозиції будь-якого постачальника ESB стосуються моделі розгортання мікросервісів або розміщеної в їх власній хмарі, відомої як iPAAS. Таким чином, це гарантує, що шина ніколи не вийде з ладу або вийде з ладу самолікуванням на основі обраної вами моделі розгортання. Завдяки розгортанню мікросервісів або iPAAS, тепер ESB має можливості автоматичного масштабування (горизонтально або вертикально) з різними можливостями залежно від обраного постачальника.

Для дуже високих можливостей, які надає ESB, ви можете перейти за наступним посиланням => https://en.wikipedia.org/wiki/Enterprise_service_bus