Magistrala ESB (Enterprise Service Bus)

menu icon

Magistrala ESB (Enterprise Service Bus)

Z tego przewodnika dowiesz się więcej o magistrali ESB (istotnym komponencie architektury SOA), poznasz płynące z niej korzyści oraz dowiesz się, w jaki sposób jest powiązana z architekturą mikrousług.

Czym jest magistrala ESB (Enterprise Service Bus — Korporacyjna magistrala usług)?

Magistrala ESB, czyli korporacyjna magistrala usług, to wzorzec, na podstawie którego scentralizowany komponent oprogramowania przeprowadza integracje z systemami typu back-end (i tłumaczeniami modeli danych, głęboką łącznością, routingiem i żądaniami) oraz udostępnia te integracje i tłumaczenia jako interfejsy usług do ponownego wykorzystania przez nowe aplikacje. Wzorzec ESB jest zwykle implementowany przy użyciu specjalnie zaprojektowanego środowiska wykonawczego i zestawu narzędzi integracji, które zapewniają najlepszą możliwą produktywność.

Magistrala ESB i architektura SOA

Magistrala ESB jest podstawowym komponentem architektury SOA, czyli architektury zorientowanej na usługi, która pojawiła się pod koniec lat dziewięćdziesiątych. Architektura SOA definiuje sposób, w jaki komponenty oprogramowania mogą być ponownie wykorzystywane za pośrednictwem interfejsów usług. Te interfejsy wykorzystują wspólne standardy komunikacyjne w taki sposób, aby mogły być szybko włączone do nowych aplikacji bez konieczności przeprowadzania za każdym razem głębokiej integracji.

Każda usługa w architekturze SOA zawiera kod i integracje danych wymagane do wykonania pełnej, odrębnej czynności biznesowej (np. sprawdzenia kredytu klienta, obliczenia miesięcznej spłaty pożyczki lub rozpatrzenia wniosku o kredyt hipoteczny). Interfejsy usług zapewniają luźne powiązania, co oznacza, że można je wywoływać z niewielką lub żadną wiedzą na temat sposobu implementacji integracji. Usługi są udostępniane przy użyciu standardowych protokołów sieciowych — takich jak protokół SOAP (prosty protokół dostępu do obiektów)/HTTP lub JSON/HTTP — w celu wysyłania żądań odczytu lub zmiany danych. Usługi są publikowane w sposób, który umożliwia programistom ich szybkie znajdowanie i ponowne wykorzystywanie do tworzenia nowych aplikacji.

Usługi te można tworzyć od podstaw, ale często są tworzone przez udostępnianie funkcji z wcześniejszych systemów rejestrowania jako interfejsy usług. To tu pojawia się potrzeba zastosowania magistrali ESB. Wcześniejsze systemy i systemy rejestrów są zwykle oparte na starych protokołach i zastrzeżonych formatach danych, które muszą być przetłumaczone i zintegrowane, aby działały z protokołami sieciowymi SOA. Magistrala ESB wykonuje te tłumaczenia i integracje na bieżąco. Można wdrożyć architekturę SOA bez magistrali ESB, ale właściciele aplikacji musieliby znaleźć własny, unikatowy sposób ujawnienia interfejsów usług, co wymaga dużo pracy (nawet jeśli interfejsy są wielokrotnego użytku) i stwarza poważne wyzwanie związane z przyszłymi pracami konserwacyjnymi.

Aby dowiedzieć się więcej o architekturze SOA i roli magistrali ESB, zobacz „Wprowadzenie do architektury SOA (architektura zorientowana na usługi)”.

Korzyści

Teoretycznie scentralizowana magistrala ESB oferuje możliwość standaryzacji — i radykalnego uproszczenia — komunikacji i integracji usług w całym przedsiębiorstwie. Koszty sprzętu i oprogramowania mogą być współdzielone, serwery wystarczy udostępnić tylko raz, a jednemu zespołowi specjalistów można zlecić opracowanie i zachowanie integracji (i w miarę potrzeby przeszkolić pod tym kątem).

Programiści mogą używać jednego protokołu do „komunikacji” z magistralą ESB i wydawania poleceń, które kierują interakcjami pomiędzy usługami, a z kolei magistrala ESB tłumaczy polecenia, przekierowuje wiadomości i przekształca dane w celu wykonania poleceń. Dzięki temu programiści mogą poświęcać znacznie mniej czasu na integrację, a znacznie więcej uwagi poświęcić konfiguracji i ulepszaniu aplikacji. A możliwość ponownego wykorzystania integracji z jednego projektu w innym projekcie umożliwia jeszcze większą produktywność i oszczędność na późniejszym etapie.

Jednak choć magistrala ESB została pomyślnie wdrożona w wielu organizacjach, w innych zaczęto ją postrzegać jako wąskie gardło we wdrażaniu architektury SOA. Wprowadzanie zmian lub ulepszeń w jednej integracji często destabilizowało inne. Aktualizacje oprogramowania specjalistycznego ESB często miały wpływ na istniejące integracje. Zespoły ds. aplikacji oczekiwały w kolejce na integracje, ponieważ magistrala ESB była zarządzana centralnie. Wraz ze wzrostem wolumenu integracji wdrażanie wysokiej dostępności i usuwanie skutków awarii w serwerach ESB stało się bardziej kosztowne. Jako projekt obejmujący wiele przedsiębiorstw magistrala ESB okazała się trudna do sfinansowania, co znacznie utrudniło stawienie czoła tym technicznym wyzwaniom.

Ostatecznie wyzwania związane z utrzymaniem, aktualizacją i skalowaniem scentralizowanej magistrali ESB okazały się tak przytłaczające i kosztowne, że magistrala ESB często powodowała opóźnienie wzrostu produktywności, którą miała zwiększać wraz z architekturą SOA, co frustrowało zespoły firmowe oczekujące większego tempa innowacji.

Aby dowiedzieć się więcej na temat wzlotu i upadku ESB, przeczytaj opracowanie „Los magistrali ESB”.

Magistrala ESB a mikrousługi

Architektura mikrousług umożliwia rozbicie elementów wewnętrznych pojedynczej aplikacji na małe części, które można poddawać niezależnym zmianom, skalowaniu i administracji. Mikrousługi pojawiły się i zyskały na popularności wraz z rozwojem wirtualizacji, przetwarzania w chmurze, zwinnych praktyk programistycznych i modelu DevOps. W tych kontekstach mikrousługi oferują niżej opisane możliwości:

  • Większa sprawność i produktywność dla programistów, którzy mogą wprowadzać nowe technologie do jednej części aplikacji bez naruszania lub „wychwytywania” pozostałej części aplikacji.
  • Prostsza, bardziej opłacalna skalowalność dzięki umożliwieniu skalowania dowolnego komponentu niezależnie od innych w celu jak najszybszej reakcji na wymogi dotyczące obciążeń i najbardziej efektywnego wykorzystania zasobów obliczeniowych.
  • Większa odporność, ponieważ awaria jednego komponentu nie wpływa na pozostałe, a każda mikrousługa może funkcjonować zgodnie z własnymi wymogami dostępności, nie wymuszając na innych komponentach dostosowania się do wymogu „największej wspólnej dostępności”.

Taką samą szczegółowość, jaką mikrousługi wnoszą do projektowania aplikacji, można wprowadzić do integracji, aby uzyskać podobne korzyści. Taka jest idea zwinnej integracji, która rozkłada magistralę ESB na małe, zdecentralizowane komponenty integracji bez współzależności, aby poszczególne zespoły ds. aplikacji mogły posiadać te komponenty i samodzielnie nimi zarządzać.

Aby uzyskać więcej informacji na temat mikrousług, przeczytaj dokumenty „Mikrousługi: kompletny przewodnik”, „Architektura SOA a mikrousługi: jaka jest różnica?” oraz obejrzyj film Dana Bettingera „Czym są mikrousługi?”:

Magistrala ESB i chmura IBM Cloud

Gdy Twoja firma przeniesie swoją infrastrukturę IT do chmury hybrydowej, istnieje duże prawdopodobieństwo, że przekształci różne obciążenia, także te oparte na wzorcach SOA i ESB, w bardziej lekkie i elastyczne modele wdrożeniowe. Takie transformacje to tylko jeden z  etapów modernizacji aplikacji w procesie przechodzenia organizacji do chmury.  

Wykonaj kolejny krok:

  • Sprawdź, jak możesz wykorzystać, rozszerzyć i zmodernizować inwestycje na oprogramowanie pośredniczące dzięki IBM Cloud Pak for Integration.
  • Dowiedz się, jak połączyć wszystkie swoje aplikacje i dane w wielu chmurach prywatnych i publicznych w celu spersonalizowania obsługi klienta — odwiedź stronę IBM Cloud Integration.

Załóż konto IBM Cloud już dzisiaj.