Magistrala usługowa łączy aplikacje

Technologie integrowania aplikacji w przedsiębiorstwie - Enterprise Application Integration (EAI) - przebyły już długą drogę od wczesnych prób "ręcznego" łączenia wybranych aplikacji. W owych czasach cele były umiarkowane, praca trudna, a rezultaty niepewne. Uzyskiwane rozwiązania były także kosztowne w utrzymaniu. Jakiekolwiek zmiany wymagały rozpoczynania wszystkiego od początku.

Technologie integrowania aplikacji w przedsiębiorstwie - Enterprise Application Integration (EAI) - przebyły już długą drogę od wczesnych prób "ręcznego" łączenia wybranych aplikacji. W owych czasach cele były umiarkowane, praca trudna, a rezultaty niepewne. Uzyskiwane rozwiązania były także kosztowne w utrzymaniu. Jakiekolwiek zmiany wymagały rozpoczynania wszystkiego od początku.

W ostatnim czasie daje się zauważyć coraz wyraźniejszą tendencję do łączenia aplikacji w celu tworzenia procesów biznesowych, takich jak systemy zamówień online. Systemy IT muszą adaptować się szybko do potrzeb biznesu i nie brakuje dostawców warstw pośredniczących obiecujących wykonanie tego w sposób szybki. "Magicznymi" składnikami takich ofert są SOA (Service Oriented Architecture) - paradygmat integracji wprowadzający otwarte standardy i rozproszone komponenty - oraz ESB (Enterprise Service Bus). Ta ostatnia to niedawno wykreowana platforma integracyjna zaprojektowana w celu wsparcia architektury SOA i połączenia jej z dziedziczonymi (tradycyjnymi) zasobami.

Czym jest ESB?

ESB jest opartą na standardach, zorientowaną na usługi strukturą o możliwościach łączenia setek punktów końcowych aplikacji. ESB łączy - w celu wiarygodnego komunikowania i koordynowania współdziałania aplikacji - platformy wymiany komunikatów, web services, XML, transformacje i zarządzanie danych.

Model wdrożeniowy ESB to zintegrowana sieć współpracujących węzłów usługowych, rozprowadzanych w zasobnikach usług.

Zasobniki usług są dostarczane do specyficznych części sieci - zależnie od lokalizacji aplikacyjnych punktów końcowych i wymaganego rozmieszczenia usług integracyjnych, takich jak transformacja i inteligentny routing. Zasobniki usług są podłączane do topologii szyny logicznej przez serwery komunikacyjne.

Aplikacje współdziałają za pośrednictwem wiadomości XML, które wchodzą i wychodzą do/z zasobników usług przez punkty końcowe aplikacji. Aplikacje nie muszą się "martwić" protokołami komunikacyjnymi czy fizyczną lokalizacją - widzą one jedynie skrzynki wejściowe i wyjściowe. Dzięki takiemu rozwiązaniu usługi mogą być rozszerzane, przemieszczane lub podmieniane bez zakłócania pracy istniejących systemów biznesowych lub konieczności modyfikowania aplikacji.

Używany przez ESB język XML zapewnia wysoki poziom elastyczności i sprawia, że infrastruktura jest bardziej odporna na zmiany aplikacji i procesów biznesowych. I tak, używając arkuszy stylu XML, ESB może transformować zawartość wiadomości z jednego formatu na inny. Aplikacje nie muszą więc dostosowywać się do specyficznego formatu, a dane nie muszą być wysyłane do centralnej lokalizacji w celu transformacji.

ESB traktuje wszystkie aplikacje jako usługi - niezależnie od tego, jak są podpięte do szyny, umożliwiając stopniowe przechodzenie do architektury opartej na usługach, z minimalnym ryzykiem i niewielkim zakresem inwestycji dla przedsiębiorstwa. Z pomocą niezależnych narzędzi można stosunkowo łatwo tworzyć interfejsy usługowe dla aplikacji wbudowanych w Java 2 Platform Enterprise Edition lub środowisko .Net Microsoftu.

Co więcej, ESB zapewnia kilka opcji umożliwiających obsługę istniejących już aplikacji. Powszechnie stosowanym podejściem jest używanie adapterów specyficznych dla aplikacji. Adapter taki do interakcji z ESB używa wiadomości XML - prezentującej się na szynie jako właściwa usługa - używając jednocześnie transferu niesformatowanych plików do interakcji z docelową aplikacją. Adaptery aplikacyjne są pisane zazwyczaj przez dostawców niezależnych i zapewniają połączenie pomiędzy wymaganym przez ESB interfejsem usługi sterowanej wiadomościami a rodzimym interfejsem aplikacji docelowej.

Każda usługa jest opisana we wspólnym katalogu. Projektant łączy aplikacje, wyszukując usługi w katalogu i następnie aranżując ich interakcje. Do wykonywania takiej aranżacji ESB używa inteligentnego routingu. Marszruta XML zawiera "rozkaz wymarszu" określający wymaganą sekwencję usług, przez które wiadomość musi przejść w celu skompletowania całego procesu.

Routing wiadomości może zmieniać się zgodnie ze zdarzeniami zachodzącymi w czasie rzeczywistym i zawartością wiadomości.

Technologie używane w ramach ESB są oparte na standardach. Jest to cecha niezwykle ważna, która może mieć niebagatelny wpływ na zakres zlecenia projektów integracyjnych na zewnątrz.

Stan obecny

Magistrala usługowa łączy aplikacje

Enterprise Service Bus

Za ESB stoją marzenia o zastąpieniu specyficznych brokerów integracji otwartą warstwą komunikacyjną, przez którą mogą być łatwo eksponowane zarządzane usługi rozproszone i procesy biznesowe. Obecna sytuacja jest jednak taka, iż prawdopodobnie jest jeszcze zbyt wcześnie na odstawianie tradycyjnych systemów wymiany wiadomości.

Bez względu na dostępne jądro messagingu ESB musi jakoś - poprzez otwarte standardy lub środki własne - stworzyć podstawy wiarygodnego systemu wymiany wiadomości (reliable messaging). Dopóki nie pojawi się powszechnie akceptowana specyfikacja WS-*, taka wiarygodność ciągle jeszcze zapewniana jest przez motory messagingu projektowane we własnym zakresie, podobne do JMS (Java Message Service), własnych MOM (Message-Oriented Middleware) i serwerów J2EE. Dostępne na rynku pakiety zawierają także podsystemy tradycyjnego messagingu.

Co więcej musi zapewniać zestaw ESB? Powinien mieć narzędzia upraszczające projektowanie, motor transformacji danych, inteligentny routing wiadomości i interfejs zarządzania - zapewniający monitorowanie w czasie rzeczywistym i obsługę wyjątków - jak również wdrażanie i zarządzanie dostępnymi usługami. Większość dostępnych na rynku produktów spełnia te wymagania.

Potrzebne są również dodatkowe mechanizmy, m.in. aranżacja i zarządzanie procesami, BAM (Business Activity Monitoring) i QoS, współdziałanie z systemami zarządzania, takimi jak HP OpenView i IBM Tivoli, oraz gotowe adaptery do szybkiej integracji z aplikacjami przedsiębiorstwa, źródłami danych, serwerami aplikacyjnymi, alternatywnym transportem itp. Często w dostępnych produktach brakuje też mechanizmów wykrywania usług, przyspieszania przetwarzania XML czy też routingu opartego na treści.

Magistrala pod różnymi nazwami

Definicja ESB nie jest jednolita i w dużym stopniu zależy, kto ją podaje, zwłaszcza gdy jest to duży dostawca projektujący linie produktów.

Dla BEA i Oracle jądrem jest serwer aplikacyjny J2EE. Dla IBM i Microsoft to ich kolejka wiadomości.

BEA udostępniła linię produktów infrastruktury usługowej o nazwie AquaLogic wprowadzającą warstwę messaging web services w architekturze swojego serwera aplikacyjnego WebLogic. W uzupełnieniu centralnego repozytorium, do rozpoznawania i używania usług, ma on zapewniać dostateczną ochronę, monitorowanie i zarządzanie cyklem życia danych z aplikacji opartych na usługach. Narzędzia dla procesów aranżacji i kompozycji aplikacji pozostają w odległym horyzoncie czasowym.

Dla Fusion Middleware Oracle fundamentem ESB jest serwer aplikacyjny J2EE. Wbudowana obsługa BPEL (Business Process Execution Language), uzyskana drogą przejęcia firmy Collaxa, dokłada do tej mieszanki otwarty proces aranżacji. Dodano także motor egzekwowania reguł i dość przyzwoite narzędzia związane z inteligencją biznesową.

Z kolei IBM za fundament ESB przyjmuje Web-Sphere MQ 6. Rozwiązaniu MQ 6 brakuje jednak niektórych istotnych elementów, takich jak zaawansowany brokering i repozytorium wiadomości, ale firma utrzymuje, że można "zszyć" ESB, włączając inne komponenty z oferty WebSphere.

Podobną linię reprezentuje Microsoft. Indigo to wizja przyszłej infrastruktury komunikacyjnej, obejmującej szynę messagingu NSMQ i rozszerzenia dla web services. Po połączeniu z BizTalk, Indigo może na początek być koncepcyjnie zbliżone do ESB, aczkolwiek jego modularność pozostanie kluczowym czynnikiem różnicującym. Co więcej, sukces Indigo jest bezpośrednio związany z rozpowszechnieniem obsługi protokółów WS-* implementowanych przez Microsoft.

W miarę jak uznani dostawcy warstw pośrednich przyśpieszają prace związane z modelem szyny usługowej, wczesnym dostawcom tej technologii coraz trudniej będzie utrzymać swoją pozycję. Można się spodziewać, że wielu z nich zostanie wchłoniętych przez większych graczy, a część po prostu zniknie. Dzisiejszy użytkownik powinien przyjąć takie założenia za punkt wyjścia. Jeżeli nie można bezszwowow wymienić zasobów szyny usługowej nabytej dzisiaj na elementy, które oferowane będą jutro przez tych czy innych dostawców, to czy należy czekać na konsolidację tego rynku, czy też kontynuować podążanie pierwotną linią EAI? Podróż tę należy planować ostrożnie. Droga może skręcić szybciej niż nam się wydaje.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200