Autobus usług korporacyjnych

Wszystkie działy obsługi klienta komunikują się z ESB w ten sam sposób: ESB tłumaczy komunikat na właściwy typ komunikatu i wysyła komunikat do właściwej obsługi klienta.

Magistrala usług przedsiębiorstwa ( ESB ) implementuje system komunikacji między wzajemnie oddziałującymi aplikacjami w architekturze zorientowanej na usługi (SOA). Reprezentuje architekturę oprogramowania dla przetwarzania rozproszonego i jest specjalnym wariantem bardziej ogólnego modelu klient-serwer , w którym dowolna aplikacja może zachowywać się jak serwer lub klient. ESB promuje zwinność i elastyczność w odniesieniu do komunikacji protokołów wysokiego poziomu między aplikacjami. Jego głównym zastosowaniem jest integracja aplikacji korporacyjnych (EAI) heterogenicznych i złożonych krajobrazów usług.

Architektura

Koncepcja magistrali usług przedsiębiorstwa jest analogiczna do koncepcji magistrali występującej w architekturze sprzętu komputerowego w połączeniu z modułową i współbieżną konstrukcją wysokowydajnych komputerowych systemów operacyjnych. Motywacją do opracowania architektury było znalezienie standardowej, ustrukturyzowanej koncepcji ogólnego przeznaczenia do opisu implementacji luźno powiązanych komponentów oprogramowania (zwanych usługami ), które mają być niezależnie wdrażane, uruchamiane, heterogeniczne i odmienne w sieci. ESB jest również powszechnym wzorcem implementacji architektury zorientowanej na usługi , w tym wewnętrznie przyjętego projektu sieci World Wide Web .

Nie istnieją żadne globalne standardy dotyczące koncepcji lub implementacji magistrali usług przedsiębiorstwa. Większość dostawców oprogramowania pośredniego zorientowanego na komunikaty przyjęło koncepcję magistrali usług przedsiębiorstwa jako de facto standard architektury zorientowanej na usługi. Implementacje ESB wykorzystują sterowane zdarzeniami i oparte na standardach oprogramowanie pośredniczące zorientowane na komunikaty w połączeniu z kolejkami komunikatów jako ramami technologicznymi. Jednak niektórzy producenci oprogramowania ponownie oznaczają istniejące oprogramowanie pośrednie i rozwiązania komunikacyjne jako ESB bez przyjęcia kluczowego aspektu koncepcji magistrali.

Funkcje

ESB stosuje koncepcję projektową nowoczesnych systemów operacyjnych do niezależnych usług działających w sieciach różnych i niezależnych komputerów. Podobnie jak współbieżne systemy operacyjne, magistrala ESB zapewnia podstawowe usługi oprócz przyjmowania, tłumaczenia i kierowania żądań klientów do odpowiednich usług odpowiadających.

Do podstawowych obowiązków ESB należą:

  • Kieruj wiadomości między usługami
  • Monitoruj i kontroluj routing wymiany komunikatów między usługami
  • Rozwiąż rywalizację między komunikującymi się komponentami usługi
  • Kontroluj wdrażanie i wersjonowanie usług
  • Wykorzystanie usług redundantnych przez Marshala
  • Świadczenie usług podstawowych, takich jak obsługa zdarzeń, transformacja i mapowanie danych, kolejkowanie i sekwencjonowanie komunikatów i zdarzeń, bezpieczeństwo lub obsługa wyjątków , konwersja protokołów i egzekwowanie odpowiedniej jakości usług komunikacyjnych.

Historia

Pierwsze opublikowane użycie terminu „szyna usług przedsiębiorstwa” przypisuje się Royowi W. Schulte z Gartner Group 2002 oraz książce The Enterprise Service Bus autorstwa Davida Chappella. Chociaż wiele firm przypisuje sobie ukucie tego wyrażenia, w wywiadzie Schulte powiedział, że po raz pierwszy usłyszał to wyrażenie od firmy o nazwie Candle, a następnie powiedział: „Najbardziej bezpośrednim przodkiem ESB był romski produkt Candle od 1998”, którego głównym architektem i posiadaczem wniosku patentowego był Gary Aven. Roma została po raz pierwszy sprzedana w 1998 roku, co czyni ją pierwszą komercyjną ESB na rynku, ale ten produkt Sonic z 2002 roku był również jednym z pierwszych ESB na rynku.

  • Usługa - oznacza nieiteracyjne i autonomicznie wykonujące się programy, które komunikują się z innymi usługami poprzez wymianę komunikatów
  • Magistrala - jest używana analogicznie do magistrali sprzętowej komputera
  • Enterprise - koncepcja została pierwotnie wymyślona w celu zmniejszenia złożoności integracji aplikacji korporacyjnych w przedsiębiorstwie; ograniczenie stało się nieaktualne, ponieważ współczesna komunikacja internetowa nie ogranicza się już do podmiotu korporacyjnego

ESB jako oprogramowanie

ESB jest zaimplementowana w oprogramowaniu, które działa między aplikacjami biznesowymi i umożliwia komunikację między nimi. Idealnie byłoby, gdyby magistrala ESB była w stanie zastąpić cały bezpośredni kontakt z aplikacjami na magistrali, tak aby cała komunikacja odbywała się za pośrednictwem magistrali ESB. Aby osiągnąć ten cel, magistrala ESB musi zawierać w zrozumiały sposób funkcjonalność oferowaną przez jej aplikacje składowe. Zwykle odbywa się to za pomocą korporacyjnego modelu komunikatów . Model komunikatów definiuje standardowy zestaw komunikatów przesyłanych i odbieranych przez ESB. Gdy magistrala ESB odbiera komunikat, kieruje go do odpowiedniej aplikacji. Często, ponieważ ta aplikacja ewoluowała bez tego samego modelu komunikatów, magistrala ESB musi przekształcić komunikat w format, który aplikacja może zinterpretować. Adapter programowy spełnia zadanie dokonywania tych przekształceń, analogicznie do adaptera fizycznego .

ESB polegają na dokładnym zbudowaniu korporacyjnego modelu komunikatów i odpowiednim zaprojektowaniu funkcjonalności oferowanych przez aplikacje. Jeśli model komunikatów nie obejmuje całkowicie funkcjonalności aplikacji, inne aplikacje, które wymagają tej funkcjonalności, mogą być zmuszone do ominięcia magistrali i bezpośredniego wywoływania niedopasowanych aplikacji. Takie postępowanie narusza zasady modelu ESB i neguje wiele zalet korzystania z tej architektury.

Piękno magistrali ESB polega na jej niezależnej od platformy naturze i możliwości integracji z czymkolwiek i w każdych warunkach. Ważne jest, aby związanych z zarządzaniem cyklem życia aplikacji naprawdę stosowali wszystkie możliwości ESB w swoich produktach integracyjnych, jednocześnie wdrażając architekturę SOA . Dlatego wyzwania i możliwości dla EAI polegają na zapewnieniu rozwiązania integracyjnego, które jest tanie, łatwe w konfiguracji, intuicyjne, przyjazne dla użytkownika i otwarte na dowolne narzędzia wybrane przez klientów.

Rój ESB komponentów towarowych

Charakterystyka

Kategoria Funkcje
Wezwanie obsługa synchronicznych i asynchronicznych protokołów transportowych, mapowanie usług (lokalizacja i wiązanie)
Rozgromienie adresowalność, routing statyczny/deterministyczny, routing oparty na treści, routing oparty na regułach, routing oparty na zasadach
Mediacja adaptery, transformacja protokołów, mapowanie usług
Wiadomości przetwarzanie wiadomości, transformacja wiadomości i ulepszanie wiadomości
Choreografia procesu ¹ wdrażanie złożonych procesów biznesowych
Orkiestracja usług ² koordynacja wielu usług wdrożeniowych eksponowanych jako pojedyncza, zagregowana usługa
Złożone przetwarzanie zdarzeń interpretacja zdarzeń, korelacja, dopasowywanie wzorców
Inna jakość usług bezpieczeństwo (szyfrowanie i podpisywanie), niezawodne dostarczanie, zarządzanie transakcjami
Kierownictwo monitorowanie, audyt, rejestrowanie, pomiary, konsola administracyjna, BAM (BAM nie jest funkcją zarządzania, innymi słowy ESB nie reaguje na określony próg. Jest to funkcja usługi biznesowej udostępniana użytkownikom końcowym).
Agnostycyzm ogólny agnostycyzm wobec systemów operacyjnych i języków programowania; na przykład powinien umożliwiać interoperacyjność między aplikacjami Java i .NET
Konwersja protokołu kompleksowa obsługa standardów obsługi protokołów komunikacji lokalnej
Wzorce wymiany wiadomości obsługa różnych MEP ( Message Exchange Patterns ) (na przykład: synchroniczne żądanie/odpowiedź, asynchroniczne żądanie/odpowiedź, wyślij i zapomnij, publikuj/subskrybuj)
Adaptery adaptery wspierające integrację ze starszymi systemami, ewentualnie w oparciu o standardy takie jak JCA
Bezpieczeństwo znormalizowany model bezpieczeństwa do autoryzacji, uwierzytelniania i audytu użycia ESB
Transformacja ułatwienie transformacji formatów i wartości danych, w tym usług transformacji (często przez XSLT lub XQuery ) pomiędzy formatami aplikacji wysyłającej i odbierającej
Walidacja walidacja względem schematów wysyłania i odbierania komunikatów
Zarządzanie umiejętność jednolitego stosowania reguł biznesowych
Wzbogacenie wzbogacanie wiadomości z innych źródeł
Podziel i połącz dzielenie i łączenie wielu komunikatów oraz obsługa wyjątków
Abstrakcja zapewnienie ujednoliconej abstrakcji na wielu warstwach
Routing i transformacja warunkowe kierowanie lub przekształcanie wiadomości w oparciu o niescentralizowaną politykę (bez potrzeby centralnego silnika reguł)
Usługi towarowe udostępnianie powszechnie używanych funkcji jako usług wspólnych w zależności od kontekstu

¹ Niektórzy nie traktują choreografii procesu jako funkcji ESB. Na przykład patrz M. Richards.

² Podczas gdy choreografia procesów wspiera wdrażanie złożonych procesów biznesowych, które wymagają koordynacji wielu usług biznesowych (zwykle przy użyciu BPEL ), orkiestracja usług umożliwia koordynację wielu usług wdrożeniowych (najlepiej prezentowanych jako usługa zagregowana) w celu obsługi indywidualnych żądań.

Rozwiązania te często koncentrują się na funkcjach ESB niskiego poziomu, takich jak łączność, routing i transformacja, i wymagają kodowania lub pisania skryptów w celu zaimplementowania orkiestracji. Deweloperzy działający na poziomie projektowym lub taktycznym, np. po prostu próbując rozwiązać problem, często skłaniają się ku lekkim technologiom magistrali usług, ale często istnieje ciągłe napięcie między tymi inicjatywami a architekturą korporacyjną, której celem jest optymalizacja infrastruktury w wielu projektach.

Jeśli broker komunikatów, oprogramowanie ESB, tłumaczy komunikat z jednego formatu na inny, to tak jak w przypadku każdego tłumaczenia, pojawia się kwestia semantyki komunikatu. Na przykład rekord może zostać przetłumaczony z JSON na XML, ale ten sam zestaw pól może być różnie interpretowany przez różne aplikacje, szczególnie w przypadku różnych przypadków narożnych, które zwykle są znane tylko programistom posiadającym duże doświadczenie z aplikacją który jest podłączony do ESB. W przypadku znanych przypadków narożnych liczba testów obejmujących wszystkie przypadki narożne rośnie wykładniczo z każdą aplikacją podłączoną do magistrali ESB, ponieważ każda aplikacja podłączona do magistrali ESB musi być testowana z każdą inną aplikacją podłączoną do magistrali ESB.

Kluczowe korzyści

  • Możliwość skalowania od rozwiązań punktowych po wdrożenia w całym przedsiębiorstwie (magistrala rozproszona)
  • Więcej konfiguracji zamiast kodowania integracji
  • Brak centralnego silnika reguł, brak centralnego brokera
  • Łatwy system podłączania i wyjmowania oraz luźno łączący

Kluczowe wady

  • Wolniejsza prędkość komunikacji, szczególnie w przypadku usług już kompatybilnych
  • Pojedynczy punkt awarii może spowodować przerwanie całej komunikacji w przedsiębiorstwie
  • Wysoka złożoność konfiguracji i konserwacji

Produkty

Zobacz też: Porównanie oprogramowania do integracji biznesowej

Godne uwagi produkty to:

Zobacz też

Dalsza lektura

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Enterprise_service_bus&oldid=1131567927 ”