Różnica między Message Broker a ESB

Przejrzałem różne pytania / artykuły na temat brokerów wiadomości i ESB (nawet w przypadku przepełnienia stosu). Nadal nie mam pojęcia, ponieważ jaka jest CLEAR rozgraniczająca różnica między Message Broker a ESB? Teraz próbuję porównać produkty, Websphere Broker i Mule ESB !!

Po pierwsze, czy (dowolna wersja) Webshere Broker jest ESB? Nasi faceci od produktów IBM twierdzą, że jest to ESB! (Nie jestem tym zaskoczony).

Z moich ograniczonych informacji wynika, że ​​Message Broker działa w modelu HUB-SPOKE. Jednak ESB działa na architekturze magistrali. Co to u licha ma znaczyć? Czytałem, że jeśli HUB ulegnie awarii (chyba niedostępny), to broker całkowicie zawiedzie. Co nie jest przypadkiem ESB (tak mówią ci faceci). To, czego tutaj nie rozumiem, to „Co jeśli BUS” zawiedzie?

Zwykle w ESB i Brokerach jest to, że zapewniają routing, transformację, orkiestrację itp. Więc jeśli obaj zapewniają to, to dlaczego miałbym wybierać jednego zamiast drugiego.

Innym obszarem konfliktu jest TRANSFORMACJA. Czy ESB ułatwiają to w inny sposób niż brokerzy wiadomości? Naprawdę chciałbym mieć wgląd w to.

Teraz mowa o skalowaniu POZIOMYM. Kto jest lepszy od kogo? Lub czy oba są równie skalowalne pod względem złożoności (lub innych czynników). Oczywiście pod względem kosztów, Broker Webshpere pobierze opłatę za każde pudełko (nie mówiąc już o każdym procesorze). Myślę, że nawet komercyjny MULE ESB tego nie robi. Pomijając część kosztów, jakie są konsekwencje skalowania ESB i skalowania Message Broker. Tak się składa, że ​​wiem, że w ESB można skalować do poziomu usług. Czy jest to możliwe w Message Broker?

Możesz użyć brokera transformacji bez magistrali usług i odwrotnie. Jeśli chodzi o konkretne produkty, nie sądzę, aby ktokolwiek był tylko jednym lub drugim, ponieważ wzajemnie się uzupełniają. Niektóre produkty są silniejsze w jednym obszarze, inne w innym. Być może należy dokonać wyboru w oparciu o to, która funkcja najlepiej opisuje indywidualny problem.

Broker może mieć lepsze wbudowane „klocki lego” do konstruowania łańcucha transformacji niż produkt ESB. Broker wprowadzony do służby jako ESB może zostać zmiażdżony pod obciążeniem i nie skalować się dobrze lub może brakować solidnych dzienników i narzędzi do obsługi czasopism.

Niektóre ESB pozwalają na wycofanie aktualizacji bazy danych i ponowne odtworzenie kolejek do poprawionej aplikacji po wykryciu i naprawieniu rażącego błędu w logice. Nie sądzę, by większość brokerów integruje ten poziom wsparcia transakcyjnego. Aby to zadziałało we wszystkich Twoich „transakcjach”, muszą to być wydarzenia biznesowe (sprzedaż, odnowienie, zmiana właściciela itp.), A nie coś w rodzaju „aktualizacji bazy danych” RPCish.

Zastrzeżenie: jestem konsultantem IBM i specjalizuję się w WebSphere ESB. Ten komentarz nie jest pozostawiony w żadnym oficjalnym charakterze.

ESB to bardziej wzorzec lub koncepcja architektoniczna niż produkt - ogólnie rzecz biorąc, oparty na usługach sposób inżynieryjnego luźnego połączenia. Jego definicja jest dyskusyjna i nie do końca osadzona w kamieniu. Ogólnie rzecz biorąc, ESB jest zbiorem niepowiązanych (w sensie technicznym) usług - odsłaniają interfejsy i zużywają je z innych usług. Ogólnie rzecz biorąc, nie jest zaangażowana architektura centrum i szprych, chociaż może być.

IBM z pewnością sprzedaje zarówno WebSphere Message Broker, jak i WebSphere ESB jako produkty, które ułatwiają zbudowanie ESB (wraz z urządzeniem sprzętowym DataPower). Mają różne korzenie technologiczne, ale ich przeznaczenie częściowo się pokrywa. Nie oznacza to również, że nie można zbudować ESB z wieloma innymi rzeczami, które nie są oznaczone jako „produkt ESB”.

To nie odpowiada na wszystkie Twoje pytania, ale miejmy nadzieję, że dotyczy części IBM.

Różnica między Message Broker a ESB (Enterprise Service Bus) polega głównie na słowie „magistrala”.

Dla mnie Message Broker to jeden (zwykle duży) proces, który przekształca dane z jednej struktury w inną strukturę lub modyfikuje zawartość.

ESB to oprogramowanie pośredniczące zorientowane na komunikaty (MOM) oraz dodatkowe usługi, z których jedną może być Message Broker. Tak więc ESB może zawierać Message Broker jako jeden ze swoich komponentów. Magistrala składa się z więcej niż jednego procesu, w przeciwnym razie nie nazwałbym jej „magistralą”. Charakter magistrali polega na tym, że istnieje wiele komponentów obsługujących różne zadania, z których każdy komunikuje się przez MOM i stosuje się do jakiejś formy „wspólnego formatu danych”. Magistrala składałaby się z: aplikacji wysyłających dane do MOM, adapterów baz danych, brokerów wiadomości, mostków MOM itp.

Separacja jest nieco stopniowa, ale największą różnicą między architekturą Message Broker a magistralą jest szczegółowość . Jeśli Twoim zadaniem jest integracja aplikacji A, B, .., Z i kilku baz danych, możesz to zrobić z jednym dużym Message Broker łączącym wszystkich i wszystkich. Lub z ESB, w którym wiele małych komponentów przejmuje tylko małe zadania. Na przykład jeden adapter łączy się z A, inny z B (ale nie dokonują transformacji), a następnie każdy z nich wysyła swoje rzeczy do jednego (lub więcej) Message Brokera, z których każdy powinien być tak prosty, jak to tylko możliwe - np. Nie znajomość modelu danych „A” lub „B”. Dobra magistrala ESB powinna mieć wspólną definicję danych na magistrali, abstrahującą od „odmienności” poszczególnych aplikacji.

TRANSFORMACJA: ESB nie pomaga w transformacji, chyba że jest wyposażony w Message Broker. Ale każda dobra ESB i tak powinna zawierać Message Broker. Broker komunikatów powinien być ekspertem w dziedzinie transformacji, ale nic poza tym.

Skalowanie HORYZONTALNE: jeśli masz tylko 3 rzeczy do połączenia (teraz i na zawsze), prawdopodobnie nie warto podejmować wysiłków, aby uzyskać pełnowartościową ESB. Broker komunikatów ma tę zaletę, że jest tylko jednym dużym procesem. Możesz tam skonfigurować wszystko i mieć centralną lokalizację dla wszystkich mapowań danych, filtrowania i routingu.

Ale jeśli masz 30 aplikacji do połączenia, jeden Message Broker prawdopodobnie zatrzymałby się. Oczywiście możesz kupić więcej instancji, uruchamiać zbędne rzeczy itp., Ale powinieneś zmienić swoją strategię, aby „zlokalizować” zadania. Adapter każdej aplikacji (może to być jedna mała instancja Message Broker) powinien być w stanie generować i / lub odbierać abstrakcyjny wspólny model danych (np. XML ze współdzielonym XSD). Mógłby również istnieć centralny Message Broker do zadań transformacji, ale ta instancja nie powinna znać modelu danych A lub B. Dlatego też ESB powinna przenieść przetwarzanie do komponentu eksperckiego zamiast trzymać wszystko w centralnym miejscu.

Właśnie przeczytałem ten artykuł Udi Dahana kilka dni temu, który może dać ci bardziej jasny obraz tego, co uważam za jedną z fundamentalnych różnic.

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

Cytowanie:

Zasada, że ​​dla danego typu zdarzenia może istnieć tylko jeden wydawca, jest jedną z rzeczy, która odróżnia autobusy od brokerów, chociaż obie oczywiście pozwalają na posiadanie wielu subskrybentów

...

Niestety istnieje wiele technologii typu brokerskiego, które są sprzedawane pod szyldem Enterprise Service Bus. Chociaż niektóre produkty można wdrażać zarówno w sposób scentralizowany, jak i rozproszony (czasami nazywany trybem „federacyjnym” lub „osadzonym”), wiele z nich nie narzuca reguły „jednego punktu końcowego publikacji na typ zdarzenia”.

Bez tego ograniczenia popełnianie błędów jest po prostu zbyt łatwe.

Mam nadzieję, że to pomoże.

Enterprise Service Bus zapewnia firmie trzy kluczowe wartości:

1. Kierowanie transakcji w oparciu o kontekst lub treść;
2. Transformacja z jednej domeny wiadomości lub transportu do innej domeny wiadomości lub transportu;
3. łączność z usługą wiele do wielu.

ESB zapewniają luźne powiązanie usług, pozwalają na odtworzenie usług w zupełnie innych kontekstach aplikacji niż wtedy, gdy usługi były pierwotnie planowane lub opracowywane, a także promują ponowne wykorzystanie aplikacji bez konieczności ponownego kodowania aplikacji. Produkt WebSphere Message Broker (obecnie nazywany IBM Integration Bus) jest najlepszym przykładem magistrali Enterprise Service Bus. Aby zapoznać się z przykładem prostoty kodu, który w kilku wierszach przynosi wielką moc, możesz obejrzeć mój post tutaj: http://soabus.org/viewtopic.php?f=3&t=13 . Podstawowa konstrukcja środowiska wykonawczego IIB nosi nazwę logicznego drzewa komunikatów(LMT). Wszystko, co chce zrobić programista, to jakiś rodzaj operacji na LMT. ESQL jest najbardziej wydajnym językiem, jakiego programista może używać do wykonywania tych operacji na LMT, chociaż obsługiwanych jest wiele innych języków (na przykład Java, PHP, Python itp.) Żaden inny produkt nie jest tak wydajny i łatwy w tworzeniu ESB aplikacji niż IBM Integration Bus, ponieważ 90% kodowania tych aplikacji odbywa się poprzez przeciąganie i upuszczanie węzłów na paletę. To pozostawia tylko 10 procent kodowania do wykonania przez programistę Message Flow. Nawiasem mówiąc, produkt WebSphere ESB został wycofany przez IBM, a wiele konkurencyjnych produktów do IBM Integration Bus nie doczekało się nowych rozwiązań od kilku lat. Listę różnych ofert produktów ESB można znaleźć na stronie soabus.org.

Od tego czasu IBM zmienił nazwy swojej oferty ESB, więc nie wchodziłbym w nazwy ani dostawców.

ESB umożliwia przepływ informacji biznesowych między różnymi aplikacjami na wielu platformach sprzętowych i programowych. ESB jest bardziej warstwą oprogramowania pośredniego, która utrzymuje logikę łączności aplikacji i minimalną logikę biznesową. Dzięki temu aplikacje mogą robić to, co robią najlepiej, nie martwiąc się o osadzenie jakiejkolwiek logiki łączności w zakresie interakcji z innymi N aplikacjami, które wymagają od nich danych. Architektura ESB jest próbą rozwiązania problemu spaghetti w przedsiębiorstwie od punktu do punktu.

ESB i Message Broker są ze sobą synonimami, jednak jedna z powyższych odpowiedzi podkreśliła, że ​​wzorzec Messages Broker jest częścią większej domeny ESB. Litera „B” w ESB jest analogiczna do szyny (sprzętu) w architekturze komputera. Magistrala na płycie głównej lub w komputerze łączy różne komponenty niezbędne do funkcjonowania komputera. ESB to oparta na oprogramowaniu magistrala łącząca różne usługi w przedsiębiorstwie. Hub and spoke to jeden z wzorców obsługiwanych przez architekturę ESB. W świecie monolitycznym każdy dostawca ma własną architekturę wdrażania o wysokiej dostępności, aby zapewnić dostępność ESB. Niedawna oferta dowolnego dostawcy ESB dotyczy modelu wdrażania opartego na mikrousługach lub jest hostowana we własnej chmurze znanej jako iPAAS. Dzięki temu usługa Bus nigdy nie zawiedzie ani nie ulegnie tymczasowej awarii dzięki samonaprawianiu na podstawie wybranego modelu wdrażania. Dzięki wdrożeniu opartemu na mikrousługach lub iPAAS, ESB mają teraz możliwości automatycznego skalowania (w poziomie lub w pionie) z funkcjami różniącymi się w zależności od wybranego dostawcy.

Aby uzyskać bardzo wysoki poziom możliwości, które zapewnia ESB, możesz przejść przez następujący link => https://en.wikipedia.org/wiki/Enterprise_service_bus