W poprzednim miejscu pracy dużo się mówiło o „Enterprise Service Bus” (ESB). Przeczytałem fragmenty książki koncepcyjnej na ten temat, ale nigdy tak naprawdę nie rozumiałem, w jaki sposób można to wdrożyć / zintegrować w konkretnych warunkach. Jestem zaznajomiony z SOA / kolejkowanie / usługi katalogowe / itp. ale nie rozumiem, czym dokładnie jest ESB.
Czy jest to konkretna rzecz (usługa / serwer / broker / itp.), Że po prostu podłączasz do niego wszystkie aplikacje na różne sposoby, czy też jest to bardziej koncepcyjny sposób projektowania systemów?
Wszelkie wyjaśnienia lub linki do dobrych przykładów będą bardzo mile widziane. Dzięki.
Odpowiedzi:
To pojęcie abstrakcji na dość wysokim poziomie. Główną koncepcją jest to, że ESB zapewnia oprogramowanie pośrednie i interfejsy, które pozwalają firmom łączyć swoje aplikacje bez pisania kodu.
Może to obejmować mediację w celu uzgodnienia niezgodnych protokołów, danych i interakcji.
Idea centralnego autobusu, w którym wszystko mija, daje możliwość dodatkowych warstw abstrakcji. Używanie standardów branżowych do „podłączania” innych aplikacji, klientów itp. Do tej magistrali sprawia, że łączenie nowych usług, źródeł danych, klientów o różnych potrzebach jest stosunkowo łatwe.
Rzeczywiste realizacje
Jeśli chodzi o rzeczywiste wdrożenia, to domena bardzo dużych firm wspierających przedsiębiorstwa. Chociaż jest to bardzo modne, cel jest ideałem, który na pewnym małym poziomie można zrozumieć poprzez porównanie z Internetem:
Podobieństwo do Internetu
Jedna duża magistrala komunikacyjna o bardzo różnych zastosowaniach i danych, ale wszystkie obsługujące standardowe protokoły.
W rzeczywistości można napisać łącznik HTTP do FTP, który umożliwi przeglądarkom dostęp do witryn FTP bez wywoływania klienta FTP (zwykle jest to obecnie wbudowane w przeglądarkę).
Mashups
Mashupy demonstrują interesującą implementację - weź kilka danych o trasach autobusów od władz San Francisco, mapę z Google i lokalizacje barów sushi z Yahoo z ocenami i uruchom proste zapytanie, które wskaże najbliższy bar sushi, ważąc go tak, abyś był chętni pojechać trochę dalej po lepszy bar.
Wszystkie zupełnie inne usługi, same w sobie niekompatybilne, ale przy użyciu standardowych łączników (np. Rur Yahoo) można je połączyć w spójną i użyteczną całość.
-Adam
źródło
Zastrzeżenie: Pracuję dla IBM i konsultuję się w sprawie WebSphere ESB, produktu IBM zaprojektowanego do tworzenia ESB. Oto moje opinie i niekoniecznie odzwierciedlają stanowisko IBM.
Niestety ESB to coś innego dla różnych ludzi.
Dla mnie ESB to dowolna technologia, którą można wstawić do SOA (architektura zorientowana na usługi), umożliwiając łączenie ze sobą różnych systemów. Często pełni funkcje transformacji protokołu, modyfikacji wiadomości, routingu, logowania, działa jako brama bezpieczeństwa i tak dalej. Na przykład można użyć ESB, aby udostępnić usługę, która wcześniej była dostępna tylko jako usługa sieci Web, również jako usługa oparta na JMS.
Pod tym względem implementacje ESB (a dokładniej oprogramowanie sprzedawane do budowania ESB - takie jak to, z którym się konsultuję) są często technologicznie podobne do tego, co było znane jako broker wiadomości lub kolejkowania, chociaż cel jest nieco inny. , ponieważ (jak sugerują akronimy) jest zorientowany na usługi, a nie przenoszenie wiadomości z jednego miejsca do drugiego. To, jak ważne jest to rozróżnienie z technologicznego punktu widzenia, jest kwestią opinii.
źródło
Moje doświadczenie z komercyjnym ESB jest takie, że jest to przesadzona i droga technologia, która stwarza tyle problemów, ile rozwiązuje. ESB połączy nowe systemy i dziedzictwo, wiadomości będą przelatywać przez autobus i wszystko będzie mogło bezproblemowo komunikować się ze wszystkim innym. Dodaj trochę odporności, orkiestracji i otrzymujesz bardzo potężne oprogramowanie aplikacji dla przedsiębiorstw.
Problem pojawia się, gdy próbujesz ich używać w rzeczywistości, koszty pisania dla autobusu, tworzenia struktur wiadomości i tak dalej mogą przeważyć korzyści. Jako pozycja o wysokim koszcie, ESB jest postrzegana jako panaceum na wszystkie problemy techniczne, którymi nie jest, zbyt dużo czasu spędza się na magistrali, a nie na podłączanych aplikacjach / danych. Często jest tak, że wiele konkurencyjnych standardów będzie walczyć o dominację w tej samej organizacji, prowadząc do silosów zdominowanych przez klasyczne technologie, które te systemy powinny faktycznie naprawiać.
IMHO znacznie lepiej jest użyć, aby utworzyć niewielką liczbę określonych interfejsów, zazwyczaj używając usług internetowych tylko między tymi systemami, które tego potrzebują.
źródło
Zasadniczo jest to koncepcyjny sposób projektowania systemu - firmy programistyczne próbują sprzedać więcej, naklejając na to naklejkę „ESB”, a menedżerowie lubią, ponieważ ESB wygląda dobrze z „wyższego poziomu”.
ESB to w zasadzie MOM (oprogramowanie pośredniczące zorientowane na komunikaty) z dodanym modelem danych i zarządzaniem definicją struktury. Masz wspólną definicję danych dla wszystkich aplikacji i adapterów na tej magistrali (może to być XML ze współużytkowanym XSD). Wszystko, co się łączy, MUSI wysłać informacje zgodne z tą definicją danych. ESB obsługuje ładowanie, udostępnianie i wersjonowanie tej wspólnej definicji danych. Podłączając nowy komponent do ESB, możesz oczekiwać większej „kompatybilności” po wyjęciu z pudełka niż po podłączeniu go do MOM. Każdy komponent na tej magistrali jest koncepcyjnie traktowany jako „zasób” - dlatego wprowadzono dodatkową abstrakcję, aby oddzielić nadawcę od odbiorcy.
Przykład: załóżmy, że chcesz połączyć aplikację A z aplikacją B w standardowym oprogramowaniu pośredniczącym zorientowanym na komunikaty, weźmy JMS. Rozmawiasz ze swoimi kolegami pracującymi nad aplikacją B, uzgadniasz temat, typ wiadomości i pola i wysyłasz ją (pseudokod): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" cena = 101,4 vol = 100})
Jeśli robisz to samo w architekturze zorientowanej na usługi, musisz to zrobić
Za pierwszym razem to pewnie trochę bolesne, ale myślę, że można się do tego przyzwyczaić, tak jak można się przyzwyczaić do EJB ;-)
Można powiedzieć, że system MOM jest „bez typu” (struktura dynamiczna), podczas gdy ESB jest „wpisana” (struktura statyczna). Kompromisy między nieprzetworzoną wiadomością a ESB są podobne do innych opcji bez typu / wpisanych na maszynie:
W przypadku mniejszych projektów dobrze jest szybko skasować funkcjonalność (np. Kod Groovy), ale w przypadku większych projektów dobrze jest mieć debugger (np. Java), aby otrzymywać ostrzeżenia z wyprzedzeniem, gdy coś się zepsuje i mieć standard dla ludzi, zanim zdecydują się na projekt.
Jeśli więc twój projekt cierpi z powodu zbyt wielu osób, które łamią system, sprawdzając niewalidowane zmiany - przejdź do większej struktury (ESB zamiast MOM). Jeśli Twoje projekty cierpią na niedostateczną realizację na czas - wybierz prostsze, nietypowe rozwiązanie. Jeśli to jedno i drugie - poproś konsultanta (tylko żartuję ;-)
źródło
Cóż, to zależy od tego, kogo zapytasz ... Wielu powiedziałoby, że jest to „oprogramowanie pośredniczące”, które łączy różne elementy „logiki biznesowej” w celu wyeliminowania kodowania z komunikacji między tymi modułami. Myślę, że to dość ogólna definicja, ale jestem pewien, że już się tam dostałeś za pośrednictwem Wikipedii i tak dalej.
Ci, którzy chcieliby, aby wspaniała ESB uratowała świat, widzą ją tak, jak jest ona najczęściej prezentowana, jako centrum robienia wszystkiego. Większość implementacji ESB ma na celu hermetyzację wszystkich powtarzalnych zadań, które widzimy w oprogramowaniu biznesowym. Oznacza to, że większość ESB dba o przesyłanie danych, bezpieczeństwo, logowanie, translację protokołów, systemy zdarzeń, ekspozycję API za pośrednictwem usług internetowych itp.
Myślę, że to jest tak jasne, jak tylko mogę ... Mam nadzieję, że to pomoże.
źródło
Spójrz na moją prezentację „ Spoiled for Choice - Jak wybrać właściwą ESB ”.
Wyjaśniam, kiedy używać ESB, pakietu integracyjnego lub po prostu platformy integracji (takiej jak Apache Camel). Omawiam również różnice między otwartymi i zastrzeżonymi ESB.
źródło
Poza standardową definicją, z której można uzyskać Wikipedii . Uważam, że jest to świetne narzędzie do łączenia wielu starszych systemów na wielu platformach i technologiach. Jest to również dobre narzędzie do budowania rozproszonych przepływów pracy i systemów zarządzania stanem (takich jak księga główna).
Jest jednak dość drogi, złożony i niewygodny w utrzymaniu i rozbudowie, co sprawia, że jest to kiepski wybór technologii jako narzędzie ogólnego przeznaczenia do skalowania aplikacji.
źródło