Definicja
ESB (Enterprise Service Bus) to centralna magistrala integracyjna, która łączy wszystkie systemy w organizacji. Zapewnia routing wiadomości, transformację formatów danych i orkiestrację procesów.
Funkcje ESB
| Funkcja | Opis | Przykład |
|---|---|---|
| Routing | Kierowanie wiadomości | Zamówienie → właściwy system fulfillment |
| Transformacja | Konwersja formatów | XML → JSON, PLN → EUR |
| Orkiestracja | Koordynacja procesów | Zamówienie → płatność → magazyn → wysyłka |
| Monitoring | Śledzenie komunikatów | Logi, alerty, audyt |
| Security | Uwierzytelnianie/autoryzacja | Token validation, SSL |
| Protocol mediation | Tłumaczenie protokołów | SOAP ↔ REST ↔ JMS |
ESB vs API Gateway vs Message Broker
| Aspekt | ESB | API Gateway | Message Broker |
|---|---|---|---|
| Wzorzec | Hub-and-spoke | Request/response | Publish/subscribe |
| Złożoność | Wysoka | Średnia | Niska |
| Transformacja | Tak (bogate) | Minimalna | Brak |
| Orkiestracja | Tak | Nie | Nie |
| Era | 2005-2015 | 2015+ | Uniwersalny |
Dlaczego to ważne?
Wiele korporacji nadal korzysta z ESB. BA musi rozumieć, jak przepływają dane w organizacji i gdzie ESB jest wąskim gardłem lub enablerem integracji.
Jak nazwać ESB po polsku i z czym się go myli?
ESB to skrót od Enterprise Service Bus. W polskich zespołach krążą co najmniej cztery tłumaczenia: szyna integracyjna, dosłowna szyna usług korporacyjnych oraz rzadsze szyna usług i magistrala usług (definicja wyżej mówi o „centralnej magistrali integracyjnej"). Na spotkaniach najczęściej pada po prostu „szyna": „to idzie przez szynę", „mapowanie jest na szynie". Wszystkie te nazwy opisują to samo: jeden pośredniczący komponent, z którym łączą się systemy, zamiast łączyć się ze sobą nawzajem.
Pomyłki biorą się z trzech miejsc:
- „Szyna" jako słowo-wytrych. Deweloper, który mówi „wrzucimy to na szynę", może mieć na myśli klasyczny ESB, ale równie dobrze brokera komunikatów, np. Kafkę. Lekcja o rodzajach integracji w materiałach Analify opisuje Kafkę i RabbitMQ jako „implementacje kolejek/szyny dla messagingu". Zanim wpiszesz „ESB" do dokumentu, zapytaj, o jaki produkt chodzi.
- ESB a middleware. Middleware to szersza rodzina. Hasło o middleware wymienia szyny integracyjne obok brokerów komunikatów, API gateway i serwerów integracyjnych. Każdy ESB jest middleware'em, ale nie każdy middleware jest szyną.
- ESB a SOA. SOA to styl architektury, a ESB to narzędzie, którym ten styl często budowano. Hasło o SOA ujmuje to tak: „Historycznie SOA kojarzy się z korporacyjną szyną integracyjną (ESB), protokołem SOAP i ładem architektonicznym". Firma może mieć szynę bez architektury usługowej i usługi bez szyny.
Czym różni się integracja przez szynę od połączeń punkt-punkt?
Lekcja o rodzajach integracji rozdziela dwie osie, które w rozmowie łatwo skleić: topologię (jak systemy są ze sobą połączone) i styl wymiany (API, plik, ETL, kolejka). ESB to odpowiedź na pytanie o topologię. Przez szynę może iść zarówno wywołanie API, jak i komunikat z kolejki.
| Punkt-punkt | Szyna (ESB) | |
|---|---|---|
| Jak łączą się systemy | każdy bezpośrednio z każdym partnerem | każdy tylko z szyną |
| Liczba połączeń przy 10 systemach | do 45 | 10 |
| Gdzie żyje tłumaczenie formatów | w każdym połączeniu osobno | na szynie |
| Zmiana formatu w jednym systemie | poprawki u wszystkich jego partnerów | zmiana mapowania na szynie |
| Główny koszt | gąszcz połączeń przy kilkunastu systemach | dodatkowy komponent do utrzymania, na którym koncentruje się ryzyko |
Liczby pochodzą z lekcji: w układzie punkt-punkt trzy systemy to do 3 połączeń, pięć to do 10, dziesięć to do 45, bo liczba połączeń rośnie z kwadratem liczby systemów. Przy dwóch-trzech systemach połączenia bezpośrednie są prostsze. Szyna zaczyna się opłacać tam, gdzie systemów jest kilkanaście i każdy rozmawia z kilkoma.
Wybór topologii nie należy do analityka. Lekcja mówi wprost, że to decyzja architekta, i od razu zaznacza: „musisz wiedzieć, która obowiązuje". Od topologii zależy bowiem, gdzie opisujesz mapowanie danych i kto jest właścicielem transformacji.
Co zmienia szyna w pracy analityka biznesowego?
Z perspektywy dokumentacji szyna to dodatkowy uczestnik każdej rozmowy między systemami. Widać to w sześciu miejscach:
- Mapowanie danych ma jednego gospodarza. Tabela mapowania (pole, typ, czy wymagane, źródło) opisuje przejście przez szynę, a nie każde połączenie z osobna. Trzeba ustalić, kto ją utrzymuje: zespół szyny czy zespoły systemów po obu stronach.
- Na diagramie sekwencji pojawia się nowa linia życia. Na diagramie sekwencji szyna stoi między nadawcą a odbiorcą i to do niej biegną strzałki nadawcy.
- Diagram kontekstowy zostaje prosty. Na diagramie kontekstowym zwykle rysujesz system zewnętrzny, z którym Twój system wymienia dane, bo ten diagram pokazuje, z kim system rozmawia. Szyna trafia do opisu przepływu, gdzie zapisujesz, którędy płyną dane.
- Wymagania niefunkcjonalne dotyczą dwóch odcinków. Czas odpowiedzi i dostępność trzeba rozpisać osobno dla szyny i dla systemu docelowego, bo komunikat przechodzi przez oba. Hasło o middleware wylicza, co rozstrzyga się w warstwie pośredniej: „Opóźnienia, gwarancje dostarczenia, kolejność komunikatów, obsługa duplikatów". Każda z tych rzeczy to wymaganie niefunkcjonalne albo pozycja w SLA.
- Awaria odbiorcy nie musi być awarią nadawcy. Hasło o middleware pokazuje to na MediFlow: portal pacjenta mówi w REST/JSON, stary system HIS w HL7, a szyna tłumaczy formaty. Gdy HIS wyłącza się na nocny backup, szyna kolejkuje rezerwacje i dosyła je po wznowieniu. To zachowanie analityk zapisał jako wymaganie, zanim architekci wybrali rozwiązanie.
- Test integracyjny ma więcej punktów kontroli. Przy testowaniu integracyjnym sprawdzasz, czy komunikat wszedł na szynę, czy został poprawnie przetłumaczony i czy dotarł do odbiorcy. Monitoring, który góra hasła wymienia wśród funkcji ESB (logi, alerty, audyt), jest wtedy Twoim źródłem dowodu.
Jakie pytania zadać, gdy w projekcie pojawia się ESB?
Poniższa lista opiera się na lekcjach o integracjach i kolejkach w materiałach Analify, przykłady w dwóch ostatnich wierszach to nasze uzupełnienie. Każda odpowiedź ma w dokumentacji swoje miejsce:
| Pytanie | Po co je zadajesz | Gdzie zapisujesz odpowiedź |
|---|---|---|
| Czy ten przepływ idzie przez szynę, czy bezpośrednio? | od tego zależy, gdzie opisujesz mapowanie | opis przepływu, pytania otwarte |
| Kto jest właścicielem mapowania i transformacji? | zmiana jednego pola to czyjaś praca i czyjś termin | tabela mapowania danych |
| Wymiana synchroniczna czy asynchroniczna? | przy API opisujesz kody błędów i limity czasu, przy kolejce los nieprzetworzonego komunikatu | scenariusze brzegowe |
| Co szyna robi, gdy odbiorca nie odpowiada? | ponowienia, kolejka błędów, alert, jak długo czekamy | wymagania niefunkcjonalne |
| Czy ten sam komunikat może dojść dwa razy? | przy gwarancji „co najmniej raz" duplikat jest możliwy i system musi go obsłużyć | wymaganie idempotencji dla operacji zapisu |
| Czy kolejność komunikatów ma znaczenie? | np. zmiana adresu klienta nie może dojść po wysyłce, która z niego korzysta | wymagania niefunkcjonalne |
| Kto widzi logi przepływów? | przy incydencie ktoś musi znaleźć zgubiony komunikat | procedura obsługi incydentu |
Pierwsze pytanie warto zadać nawet wtedy, gdy wydaje się oczywiste. W przykładzie z lekcji o rodzajach integracji analityk zostawia w specyfikacji pytanie otwarte do architekta: czy webhook płatności i zdarzenie o złożeniu zamówienia idą przez wspólną szynę. Dwa przepływy, które na diagramie biznesowym wyglądają niezależnie, mogą dzielić jedną infrastrukturę, a więc i jedną awarię.
Pytanie o duplikaty wynika z lekcji o kolejkach: gdy pośrednik gwarantuje dostarczenie „co najmniej raz", odbiorca może dostać ten sam komunikat dwukrotnie. Wymaganie brzmi wtedy biznesowo. Lekcja formułuje je tak: powtórne przetworzenie zdarzenia „nie może utworzyć drugiej faktury ani wysłać drugiego e-maila". Techniczne rozwiązanie wybiera zespół.
Czy ESB to przestarzała technologia?
Tabela porównawcza w górze hasła przypisuje ESB lata 2005-2015, a sekcja „Dlaczego to ważne?" przypomina, że wiele korporacji nadal z niego korzysta. Obie rzeczy są prawdą naraz.
Nowe systemy budowane w mikroserwisach zwykle odchodzą od centralnej szyny. Hasło o SOA opisuje mikrousługi jako działające „bez centralnej szyny, z decentralizacją danych". Logika biznesowa zostaje w usługach, a pośrednik, np. broker zdarzeń w architekturze sterowanej zdarzeniami, tylko przenosi komunikaty. Szyny zbudowane wcześniej działają dalej, bo przeniesienie kilkudziesięciu integracji naraz to duży i ryzykowny projekt.
Dla analityka wynika z tego jedno: ESB rzadko jest wymaganiem z ogłoszenia, za to często czeka w projekcie. Zestawienie umiejętności z job boardu Analify z 27.09.2026 obejmuje 275 aktywnych ofert i 15 najczęściej wymaganych umiejętności. W tej piętnastce nie ma ani ESB, ani szyny, a REST API pojawia się w 16 ofertach, UML w 36, BPMN w 37. Lekcja o kolejkach zauważa z kolei, że w ofertach dla analityków coraz częściej padają nazwy Kafka, RabbitMQ i message broker. Sama szyna żyje w organizacjach z wieloma starszymi systemami. Wpis o integracji API dla analityka przypomina, że SOAP, protokół kojarzony z erą szyn, jest „wciąż spotykany w bankowości i systemach korporacyjnych".
Jak odpowiedzieć na pytanie o ESB na rozmowie?
Definicja z pamięci to za mało, żeby się wyróżnić. Mocniejsza odpowiedź ma trzy zdania:
- Czym jest: „ESB to szyna integracyjna: systemy łączą się z nią zamiast ze sobą nawzajem, a ona kieruje komunikaty do odbiorców i tłumaczy formaty."
- Po co i za jaką cenę: „Przy kilkunastu systemach zastępuje gąszcz połączeń punkt-punkt jednym miejscem na routing, transformację i monitoring, ale sama staje się komponentem, którego awaria dotyka wszystkich."
- Co robi przy niej analityk: „Ustalam, czy przepływ idzie przez szynę, opisuję mapowanie danych i to, co ma się stać, gdy odbiorca nie odpowiada albo komunikat przyjdzie dwa razy."
Możliwe dopytania i krótkie odpowiedzi:
- „Czym ESB różni się od API gateway?" Gateway stoi przed usługami i obsługuje żądania przychodzące, szyna łączy systemy między sobą i tłumaczy formaty. Porównanie z brokerem komunikatów jest w tabeli wyżej.
- „Czy Kafka to ESB?" W klasycznym sensie nie. Lekcja o kolejkach opisuje Kafkę jako log zdarzeń, z którego wielu odbiorców czyta ten sam strumień, każdy po swojemu. Tłumaczenie formatów i routing, które ESB robi u siebie, przy brokerze zostają zwykle w usługach.
- „Jaka jest największa wada szyny?" Koncentracja ryzyka w jednym miejscu. Lekcja o rodzajach integracji nazywa szynę dodatkowym komponentem do utrzymania i punktem, na którym skupia się ryzyko.
Gdzie iść dalej
- Architektura i integracje: SOA, middleware, API, REST, webhook, mikroserwisy, Event-Driven Architecture, ETL.
- Dokumentowanie integracji: diagram sekwencji, diagram kontekstowy, wymaganie niefunkcjonalne, SLA, testowanie integracyjne; wpis Integracja API dla analityka - REST wyjaśniony w praktyce.
- Granica ról przy integracjach: wpis Analityk systemowy a analityk biznesowy: czym się różnią.
Jeśli chcesz ćwiczyć opisywanie przepływów danych na jednym case'ie, załóż darmowe konto: dostajesz pierwszą lekcję każdego kursu, trzy podejścia do testów w miesiącu i plan na 30 dni.