Sonic

Enterprise Service Bus (ESB)

Gotowe elementy infrastruktury SOA (SOA - Service Oriented Architecture)

Skala wykorzystania i zastosowania usług webowych (potocznie – web-serwisów) w aplikacjach oraz ich dostępność w narzędziach i platformach deweloperskich jest już tak duża i powszechna, że podstawowym zadaniem do rozwiązania staje się stworzenie jednolitego spójnego środowiska niezbędnego do ich efektywnego funkcjonowania. W jaki sposób różnorodne usługi powinny być od siebie zależne, jak łączyć je w większe struktury czy sterować ich wykonaniem? Do tych pytań dochodzą także sprawy związane z monitorowaniem wykonywania usług oraz zapewnieniem odpowiedniego poziomu bezpieczeństwa i kontroli dostępu.

Poszukiwanie odpowiedzi na te pytania prowadzi do budowy infrastruktury SOA (Service Oriented Architecture), która w sposób możliwie uniwersalny i zestandaryzowany będzie w stanie łączyć  ze sobą różnorodne platformy aplikacyjne udostępniające usługi. Sposób jej budowy powinien zapewniać możliwość dynamicznego dołączania i rekonfigurowania usług, a także wprowadzania zmian w ścieżkach wykonania usług odpowiadających zmianom procesów biznesowych. Podstawowe wymagania ogólne, które stawiane są przed  infrastrukturą SOA obejmują:

• Heterogeniczność: infrastruktura musi posiadać możliwość łączenia w spójnym modelu usług - nowych aplikacji budowanych w technologii usług z już istniejącymi aplikacjami zrealizowanymi w innych technologiach
  
  
• Elastyczność: wprowadzanie zmian związanych ze zmianami procesów i zależności pomiędzy aplikacjami powinno być realizowane w oparciu o środki umożliwiające zmianę na poziomie konfiguracji, a nie zmiany w kodzie programów źródłowych
  
  
• Obsługa środowisk rozproszonych : infrastruktura powinna obejmować komponenty usług rozproszone w różnych systemach i organizacjach
  
  
• Zarządzanie konfiguracją: wyposażenie w środki umożliwiające zarządzanie i monitorowanie infrastruktury oraz włączonych komponentów usług

ESB stanowi infrastrukturę programów zbudowanych w modelu architektury usług SOA, ułatwiających integrację i elastyczne włączanie komponentów biznesowych. Dostarczana w ramach ESB funkcjonalność niezbędna do obsługi komponentów usług obejmuje: dynamiczne przyłączanie, pośrednictwo między komponentami oraz kontrolę wykonania i interakcji usług.

Przyłączanie usług

Korporacyjna magistrala usług ułatwia przyłączanie nowych aplikacji, usług webowych i wielu technologii, w oparciu o które budowano aktualnie eksploatowane systemy. Dowolna aplikacja przyłączana do ESB - bez względu na technologie w jakiej została zbudowana (J2EE, .NET, usługi webowe, bazy danych, broker komunikacyjny czy inne) staje się automatycznie zasobem, który może się komunikować z innymi komponentami włączonymi do ESB.

Pośredniczenie między usługami

Kluczową i przynoszącą szereg korzyści funkcjonalnością jaką daje zastosowanie korporacyjnej magistrali usług jest pośrednictwo pomiędzy komponentami usług. Wykorzystanie wbudowanych cech funkcjonalnych ESB pozwala w dużo prostszy sposób niż budowanie wszystkiego od zera - obsługiwać komunikację komponentów usługowych wyposażonych w niekompatybilne protokoły, formaty danych, czy posiadających różne scenariusze interakcji. Ta ostatnia cecha może być szczególnie przydatna w komunikowaniu ze sobą komponentów działających synchronicznie z asynchronicznymi i vice versa - jej zastosowanie nie wymaga wprowadzania żadnych zmian w kodzie źródłowym samych usług.

Dzięki możliwość realizacji efektywnego pośrednictwa między usługami bez konieczności ingerowania w ich kod źródłowy, znika często spotykany problem, jakim jest utrata elastyczności spowodowana zależnościami wprowadzanymi w kodzie źródłowym usług w celu ich skomunikowania. Wyodrębnienie w korporacyjnej magistrali usług warstwy realizującej pośrednictwo między usługami znacznie ułatwia zarządzanie zmianami w złożonym środowisku eksploatacyjnym.

Kolejna, związana z elastycznością, jaką daje pośrednictwo korzyść - to łatwość implementacji pojawiających się nowych wymagań poprzez grupowanie i rozszerzanie funkcjonalności już wykorzystywanych usług. Komponenty usług komunikowane ze sobą poprzez warstwę pośrednictwa stają się elementarnymi modułami, których pracą można w odpowiedni sposób sterować w celu automatyzacji całości przebiegu rzeczywistych procesów biznesowych.

Pośrednictwo między komponentami obejmuje także funkcjonalność komunikacyjną, umożliwiającą łączenie ze sobą usług rozproszonych w różnych lokacjach w zasięgu wydziałowym w całej organizacji lub  szerszym. Zawarte w ESB nowoczesne mechanizmy komunikacyjne działające w oparciu o zasadę publikacji/subskrybcji ułatwiają komponentom nadawczym symultaniczne rozsyłanie informacji do odbiorców, a także bezproblemowe dołączanie nowych komponentów do sieci odbiorców bez wprowadzania zmian w kodach źródłowych nadawców. Udostępnione w ESB wydajne, bezpieczne i skalowalne mechanizmy komunikacyjne pozwalają na budowanie rozwiązań, w których wymagane jest zagwarantowanie odpowiedniego poziomu jakości usług, a komponenty nadawcze i odbiorcze nie muszą obsługiwać problemów związanych z transmisją (np. wznawianie transmisji w przypadku braku połączenia). Warto podkreślić, że korporacyjna magistrala usług ESB nie ogranicza w żaden sposób przepustowości infrastruktury - nie stanowi wąskiego gardła, które mogłoby zawężać spektrum potencjalnych zastosowań.

Zarządzanie i kontrola konfiguracji

Wraz z rozbudową architektury usług o nowe elementy, wzrasta złożoność zarządzania i kontroli konfiguracji.  Korporacyjna magistrala usług stanowiąca podstawę infrastruktury SOA, posiada wbudowane narzędzia zarządzania magistralą i podłączonymi do niej usługami. Podstawową czynnością administracyjną jest podłączanie usług w dowolnej lokacji, w której funkcjonuje ESB. Zadanie tego typu realizuje się zwykle najpierw w środowisku deweloperskim, a następnie w testowym i w końcu w produkcyjnym. Przy pomocy narzędzi dostępnych w ESB można w sposób kontrolowany włączać usługi w jednym środowisku a następnie promować je do innego. W silnie rozproszonych środowiskach eksploatacyjnych (np. w systemach obsługujących rozległą sieć punktów sprzedaży detalicznej) włączanie usług i operacje administracyjne można realizować z jednej scentralizowanej lokacji. Włączanie jednocześnie wielu usług a także wgrywanie nowych wersji może być realizowane w sposób hurtowy - z centralnej lokacji do wielu lokacji docelowych, co znacznie ułatwia zarządzanie w bardzo rozbudowanym środowisku. Charakterystyczna właściwością ESB jest to, że zmiany konfiguracji realizowane są w sposób dynamiczny, bez konieczności rekompilacji czy ponownej instalacji - usługi i zależności pomiędzy nimi są opisywane poprzez deklaracje. Dzięki temu wprowadzanie zmian nie wymaga wyłączania już działających usług. Ponadto całość zarządzania konfiguracją w środowisku rozproszonym realizowana jest zdalnie z centralnej konsoli. Oprócz typowych mechanizmów administracyjnych i monitorujących - takich jak logi i audyt usług, błędów wykonania, statusu procesów - ESB udostępnia szczegółowe raporty wydajności, dotyczące całej infrastruktury, ułatwiające monitorowanie, detekcję błędów i diagnozowanie problemów w złożonych systemach rozproszonych.

Korzyści z zastosowania korporacyjnej magistrali usług ESB

Dla IT:

• Zmniejszenie czasu i nakładów potrzebnych do wdrożenia nowych procesów budowanych z istniejących elementów aplikacji i danych
• Zwiększona elastyczność wprowadzania zmian dzięki eliminowaniu ukrytych zależności pomiędzy aplikacjami, usługami i warstwą pośrednią w środowisku rozproszonym
• Mniejszy całkowity koszt utrzymania systemu (TCO - Total Cost of Ownership), większe możliwości obsługi przyszłych potrzeb dzięki wykorzystaniu standardowych interfejsów i protokołów
• Zapewnienie niezawodności wymiany komunikatów pomiędzy komponentami usług - także w wypadku awarii oprogramowania, sieci czy sprzętu
• Realizacja silnie rozproszonej, centralnie zarządzanej infrastruktury, w której funkcjonują komponenty usług
• Realizacja rozprowadzania informacji pomiędzy działami przedsiębiorstwa, a także umożliwienie komunikacji z podmiotami zewnętrznymi - klientami i firmami partnerskimi
• Wdrażanie przyrostowe, dające możliwość przyspieszenia oddania do użytku wdrażanych elementów, a także ograniczające ryzyko występujące w dużych i złożonych projektach

Dla biznesu:

• Integracja systemów biznesowych: skrócone czasy realizacji procesów, zmniejszone koszty operacyjne, lepsza obsługa klienta, ułatwienia w procesie łączenia i przejmowania firm, ułatwione podejmowanie decyzji dzięki udostępnieniu w systemie precyzyjnej i jednolitej informacji
• Redukcja i kontrola kosztów związanych z obsługą IT dzięki zastosowaniu zestandaryzowanych komponentów biznesowych
• Zwiększone możliwości wprowadzania szybkich i efektywnych zmian w procesach biznesowych
• Szybkie wykrywanie pojawiających nowych warunków biznesowych i reagowanie na nie 

Infrastruktura SOA: Porównanie ESB i web-serwisów

Realizacja dostępu do funkcji aplikacji poprzez wydzieloną warstwę web-serwisów bazujących na standardach otwartych jest stosunkowo prosta jeśli chodzi o koncepcję i wykonanie. Jeszcze nie tak dawno web-serwisy nie były przystosowane do poważniejszych zastosowań korporacyjnych, głównie ze względu na brak protokołów komunikacyjnych gwarantujących niezawodność dostarczenia informacji. Standardy stosowane obecnie, uwzględniają już bezpieczne i niezawodne protokoły komunikacyjne, jednak poszczególne implementacje web-serwisów mogą się znacznie różnić w takich aspektach jak wydajność, skalowalność, czy poziom dostępności - bardzo istotnych w dużych zastosowaniach korporacyjnych.

Web-serwisy są wspaniałym środkiem standaryzacji usług oraz wbudowanym mechanizmem wymiany informacji w wielu aplikacjach, ale to nie wystarcza do budowy rozległej i elastycznej uogólnionej architektury SOA. Web-serwisy nie realizują mechanizmów pośrednictwa wymiany informacji między usługami, a także nie dostarczają  środowiska eksploatacji i instalowania usług. Jeśli chodzi o mechanizmy komunikacyjne, to stosując web-serwisy mamy do dyspozycji jedynie proste modele wymiany komunikatów: "żądanie-odpowiedź" oraz "wyślij i zapomnij", natomiast brak bardziej zaawansowanych modeli takich jak np. model publikacji/subskrybcji znany ze  specyfikacji  JMS stosowanej w systemach wymiany komunikatów. I chociaż język BPEL stanowi dobrą podstawę standaryzacji dla wielu podstawowych wzorców procesów, to przy zastosowaniu aktualnych standardów nie przy jego pomocy modelować bardziej złożonych procesów opisywanych wzorcami dostępnymi w notacji UML.

Organizacje pracujące nad standaryzacją web-serwisów włożyły wiele wysiłku w prace związane z modularnością i możliwościami komponowania standardów wykorzystywanych w web-serwisach. Dzięki tym pracom można stopniowo wdrażać poszczególne standardy wraz z dojrzewaniem technologii udostępnianych przez poszczególnych producentów, aż do uzyskania pełnych korzyści związanych z wymianą informacji poprzez web-serwisy. Sonic ESB stanowi bazę, którą można rozbudowywać w sposób etapowy nie tylko o nowe usługi biznesowe, ale także w obrębie której można stopniowo włączać do eksploatacji nowe standardy - bez zakłócania pracy już eksploatowanych procesów biznesowych i usług.

Infrastruktura SOA: Porównanie ESB i platform aplikacyjnych APS (Application Platform Suites)

Platformy aplikacyjne są specjalizowanymi środowiskami umożliwiającymi eksploatację aplikacji budowanych z komponentów silnie powiązanych z potrzebnymi zasobami (przykładem silnego powiązania mogą być np. sterowniki do baz danych). Platformy aplikacyjne to wygodne narzędzia specjalizowane do budowy i eksploatacji autonomicznych aplikacji, w których nie ma częstych i istotnych zmian komponentów funkcjonalnych czy zasobów.

Realizacja przy pomocy platformy aplikacyjnej szerszej funkcjonalności niż odrębne autonomiczne aplikacje okazuje się skomplikowana, szczególnie w porównaniu z zastosowaniem w tym celu ESB. Aplikacje realizowane z pomocą platform aplikacyjnych są przeznaczone do eksploatacji na pojedynczych serwerach bądź klastrach serwerów, ich eksploatacja bądź rekonfiguracja w sieci rozproszonej obejmującej wiele różnych serwerów jest problematyczna. Podobnie też ograniczają one do jednego serwera bądź klastra realizowane procesy biznesowe i nie posiadają możliwości zunifikowanej prezentacji i zarządzania procesami realizowanymi w różnych serwerach bądź w środowisku rozproszonym. Dlatego środowiska takie jak .NET albo kontener EJB w J2EE nie są zbyt dobre do realizacji dużej ilości dynamicznie zarządzanych i konfigurowanych usług w obrębie dużej architektury SOA zastosowanej w skali całego przedsiębiorstwa.

ESB stanowi bardzo dobre uzupełnienie serwerów aplikacyjnych J2EE. Stosując ESB można dobrze integrować aplikacje w technologii J2EE z innymi aplikacjami, a także ze środowiskami innymi niż J2EE, włączając je do magistrali ESB poprzez standardowe interfejsy takie jak JMS, MDB, JCA czy web-serwisy. W przeciwieństwie do platform aplikacyjnych, kontenery magistrali ESB umożliwiają selektywne instalowanie wybranych usług przetwarzania pośredniego (ESB mediation services) w lokacjach, w których są one rzeczywiście wykorzystywane i w okresie kiedy są potrzebne. W przypadku platform aplikacyjnych nie ma takiej możliwości wybiórczego instalowania - w punktach integracyjnych zawsze musi być instalowana pełna funkcjonalność serwera aplikacyjnego, co w dłuższej perspektywie czasowej prowadzi do nieuzasadnionego zwiększenia kosztów związanych z licencjami, instalacją i utrzymaniem.

Infrastruktura SOA: Porównanie ESB i technologii MOM (Message-Oriented Middleware – pośrednia warstwa wymiany komunikatów)

Podobnie jak ESB, rozwiązania typu MOM - dzięki oddzieleniu usług warstwą pośredniego brokera komunikacyjnego - są bardziej elastyczne niż mechanizmy RPC (Remote Procedure Call - zdalne wywoływanie procedur). W produktach MOM brakuje jednak dedykowanego do usług interfejsu, a ponadto zwykle ograniczone są do jednego protokołu komunikacyjnego. W rozwiązaniach wykorzystujących MOM w kodzie źródłowym usług muszą być zaszyte bezpośrednie wywołania do warstwy komunikacyjnej oraz informacje o odbiorcach i sposobach rozsyłania komunikatów. Zmiana tak wbudowanych powiązań między usługami (np. zmiana ścieżki przetwarzania komunikatu - odpowiadająca zmianie procesu biznesowego) wymaga modyfikacji na poziomie kodu źródłowego, rekompilacji i ponownej instalacji aplikacji.

Tego typu zależności wbudowane bezpośrednio w kod programów, stanowią źródło trudności w procesie utrzymania aplikacji, wprowadzania zmian czy monitorowania wykonania. Inne problemy związane z eksploatacją usług łączonych poprzez warstwę MOM to pośrednie zależności od wbudowanego protokołu komunikacyjnego, formatów i sposobów kodowania danych, typów, struktur , modelu komponentów, mechanizmów ochrony i obsługi błędów. Produkty typu MOM nie posiadają  spotykanych w  platformach dedykowanych dla usług - mechanizmów  umożliwiających definiowanie kontraktów między usługami, rejestrowanie usług czy automatyczną detekcję usług w sieci.

Korporacyjna magistrala usług technologie typu MOM obudowuje architekturą usług. W Sonic ESB włączenie do rozwiązania integracyjnego istniejących systemów MOM - jest łatwe do wykonania i umożliwia integrację systemów bazujących na MOM z pozostałymi usługami i procesami realizowanymi w ramach ESB bądź podłączonymi do ESB.

Infrastruktura SOA: Porównanie ESB i technologii typu broker integracyjny

Tradycyjne produkty integracyjne EAI (Enterprise Application Integration) są z założenia dedykowane do integracji aplikacji. Ich konstrukcja umożliwia budowanie połączeń między aplikacjami w modelu centralnego węzła rozdzielczego (hub-and-spoke). Duża złożoność tego modelu integracyjnego spowodowana jest tym, że w jednym miejscu koncentruje się bardzo wiele powiązań między różnymi integrowanymi aplikacjami.

Przy budowie tego typu rozwiązań, programiści muszą posiadać bardzo szeroką wiedzę o danym produkcie integracyjnym i szczegółach semantycznych każdej integrowanej aplikacji - co w wielu przypadkach wymaga wysokich kwalifikacji i wiąże się z dużymi kosztami projektu integracyjnego. W obszarze eksploatacji rozwiązań integracyjnych budowanych na bazie centralnego węzła rozdzielczego typowym zagadnieniem związanym z poszerzeniem funkcjonalności jest zapewnienie odpowiednio wydajnych zasobów sprzętowych - ograniczonych w tym wypadku architekturą samego rozwiązania do pojedynczego serwera lub klastra serwerów w tym samym segmencie sieci lokalnej.