Jak po szynie

Jak połączyć dwa urządzenia? Wiadomo – kabelkiem. Jak połączyć dwa systemy? W pewnym uproszczeniu – dokładnie tak samo.

Zacznijmy od wyjaśnienia po co w ogóle łączyć. Przez wiele lat, szczególnie w małych i średnich organizacjach uważało się, że żeby system był „cool”, powinien być zintegrowany. Zintegrowany, czyli taki, który ma wszystko co potrzeba gotowe do użycia, a jego dane są przechowywane w jednym wspólnym miejscu. Taka architektura ma ogromne zalety, jest prosta, tania, łatwa w implementacji i przez to jest ogromnie popularna.

Niestety a raczej „stety” świat się zmienia. Małe organizacje konsumując korzyści systemów zintegrowanych, jednocześnie szukają rozwiązań pozwalających łączyć te systemy ze „światem zewnętrznym”. Nawet najprostsze „biznesy” wymagają dzisiaj konsumowania funkcjonalności innych systemów dostępnych głównie jako usługi w sieci. Zapisanie w systemie linka, import e-maili, wysłanie aukcji, pobranie zamówień, aktualizacja cennika, wysłanie SMS na bramkę, zlecenie mailingu, wysłanie e-deklaracji czy JPK, wszystko to są aktualne i popularne przejawy integracji systemów. Duże organizacje od zawsze, używały wielu systemów których każdy zajmował się własnym wąskim zakresem kompetencji, realizując go na jakościowo wysokim poziomie. Duże organizacje to także wymaganie skalowalności i dostępności. O dwa rzędy łatwiej zapewnić jedno i drugie jeżeli używamy wielu systemów a nie jednego. Wiadomo – jak nam „padł” system HR, to sprzedaż i inne podsystemy działają dalej.

Jak zatem integrować, łączyć, wymieniać dane i inne informacje? Dawno temu, klasycznie, choć nawet o zgrozo jeszcze dzisiaj, system łączyło poprzez jeden z największych wynalazków informatyki – plik.

 

Jeden system wysyła plik drugi system go odbiera. Ogromna prostota, jednak bardzo dużo wad. Kiedy wysyłać? Czy przyszło? Czy ktoś nie zmienił zawartości? Gdzie jest dokumentacja formatu? Czy odbiorca już pobrał? Ja mam inny format importu, jak to przetransformować? Są błędy importu, co teraz? Odpowiedzi na te wszystkie pytania są z wielu względów trudne. O jednym z nich warto wspomnieć szerzej. Struktura pliku wymiany danych ma kluczowy wpływ na jakość całego procesu. W 1996 opracowano pierwszą roboczą specyfikację XML i to rozpoczęło ogromną rewolucję. Plik XML zawiera dane ale już o nadanej strukturze i w dodatku z zadeklarowaną tożsamością. Mamy już standardy do deklarowania struktury, sprawdzania zgodności z formatem, transformowania i przetwarzania. Sytuacja ulega rewolucyjnej poprawie. Jednak dalej nie jest dobrze.

Na powyższym schemacie widać jedno optymistyczne założenie, oraz dwa niepokojące problemy których XML nie rozwiązuje. Optymistycznie zakładamy że mamy sieć (uwierzcie, nie zawsze tak było, projekt WWW trafił do CERN w 1989, a w 1992 powstała pierwsza przeglądarka). Wspomniane dwa problemy to pasywność dostawcy i transportu. Nie ma jak poprosić dostawcy o przekazanie pliku. Nie ma jak dowiedzieć się kiedy ten plik przyszedł. W dodatku trudno jest zautomatyzować cały proces. Aby rozwiązać te problemy można uciec się do różnych sztuczek (zazwyczaj mało eleganckich) np. założyć jakąś okresowość „wysyłka idzie co dziennie, o 18:30” , albo „sprawdzamy co 5 minut czy coś nie przyszło”. Wciąż słabo.

Pierwsze rozwiązanie pojawiło się już w 1988 roku jako standard RPC (Remote Procedure Call) Idea opierała się o założenie, że

jeden system może wywołać w drugim systemie

jakąś metodę przekazując jej argumenty i

odebrać z niej wyniki

 

Wydaje się to proste i jednocześnie naprawdę genialne. Jednak trzeba było jeszcze poczekać. Już w 1999, bazując na idei RPC, opublikowano specyfikację usług sieciowych w standardzie SOAP i to na zawsze zmieniło świat komunikacji systemów. Po nowemu miało to wyglądać tak:

Używamy XML jako formatu, bo ma zalety opisane powyżej. Używamy sieci jako transportu, bo jest do tego stworzona. Używamy protokołu HTTP a w zadzie HTTPS, bo daje nam to łatwość użycia i bezpieczeństwo. Umawiamy się na pewien standard (WSDL) opisu metod, danych i typów. Robiąc to wszystko mamy już naprawdę doskonałe narzędzia do integracji systemów, a nawet więcej, dajemy systemom możliwość wspólnej pracy.

Niby pięknie a jednak znaleźli się tacy, którzy zakwestionowali to osiągnięcie. Winny jest protokół HTTP oraz paru młodych pasjonatów od języka JavaScript. XML nie wszystkim się podoba, wg wielu jest nieczytelny, skomplikowany i słabo się parsuje. W 2002 roku pojawiły się wzmianki o JSON, prostym, uniwersalnym formacie przekazywania danych w postaci tekstowej, wg twórców wolnym od wad XML’a. Chwilę wcześniej, bo już w 2000, zaproponowano REST, czyli użycie metod protokołu HTTP jako sposobu na uproszczenie definiowania usług sieciowych. Od tego czasu REST i JSON w szybkim tempie opanowują świat. Powszechnie mówi się o transformacji z usług (WSDL, SOAP) do API (REST, RESTful). Można by rzec „nirwana”, mamy super architekturę, narzędzia i technologie aby integrować systemy. Jednak zobaczmy na poniższy schemat:

Systemów i integracji może być wiele. W każdej z integracji (a mamy ich na schemacie cztery) któraś ze stron musi wziąć na siebie aktywną rolę tego który będzie pytał, „strzelał” żądaniami i przetwarzał odpowiedzi. Wymaga to zmian w systemie polegających na dodaniu tych zachowań. System pasywny udostępnia tylko swoje metody/usługi. System aktywny musi mieć zakodowane zasady i metody integracji, a więc aby się zintegrować trzeba taki system zmodyfikować. Jest to ogromna wada takiej architektury. Istnieją rozwiązania oparte o dynamiczne zachowania systemów (np. DISEN w Streamsoft NEXT) które naprawiają tą wadę ale nie rozwiązują one wszystkiego.

Integracji jak widać jest wiele, w powyższym układzie zwanym PointToPoint, każdy musi opracować sposób „rozmowy” z każdym, z którym chce „rozmawiać”. Powstaje siatka zależności. Integracje są pisane wielokrotnie. Nie ma metody na zarządzanie procesami integracyjnymi. Każdy z nich jest inny, specyficzny, ale przyglądając się im z bliska widać, że muszą one rozwiązywać te same problemy np. różnice w protokołach, walidację poprawności, buforowanie i wiele innych. Co ważne (i słabe), każdy system realizuje procesy integracyjne we własnej infrastrukturze, zużywając własne zasoby.

Kolejne rozwiązanie przyszło szybko, już w 2002 można było przeczytać o ESB, korporacyjnej szynie usług, czy po prostu o szynie integracyjnej.

Idea jest prosta, każdy system integruje się tylko z szyną, a szyna zawiera logikę komunikacji wszystkich systemów. Szyna definiuje, zarządza, monitoruje, weryfikuje, buforuje, konwertuje, zwalniając systemy z tych wszystkich czynności. Integracje oparte o szynę najczęściej nie wymagają zmian w systemach które są integrowane. Trzeba zaznaczyć, że jest to tylko częściowa prawda, pewne przejawy aktywności systemów muszą zostać zachowane, choćby przez to że systemy powinny informować szynę o zdarzeniach w nich zachodzących a o których wystąpieniu chciałyby wiedzieć inne systemy. Gdyby nie to szyna musiała by stosować obejścia w rodzaju okresowego odpytywania „czy coś się wydarzyło”, co jest nieoptymalne ale w praktyce często się tak robi.

Lata doświadczeń z szynami przyniosły wiele refleksji, kiedy wdrożenie szyny ma sens, kiedy koszty poniesione na jej zastosowanie mają uzasadnienie a kiedy nie. Dziś wiemy już, że integracje PointToPoint są często wystarczające, czasami nawet lepsze, a użycie szyny zawsze musi być mocno przemyślane i nie zawsze warto wyciągać „armaty na muchę”.

Idąc dalej „jak po szynie” dochodzimy do „Streamsoft Verto ESB” czyli do szyny integracyjnej która, mam nadzieję już niedługo pojawi się w naszej ofercie. Dlaczego szyna? W niektórych naszych integracjach, a mamy ich znaczącą ilość, zaczynamy dostrzegać realną potrzebę zastosowania szyny. Nasze rozwiązanie oparte będzie o standardowe i sprawdzone komponenty, powszechnie stosowane w systemach integracyjnych. Wstępna architektura naszej szyny (nie jest jeszcze w pełni ustabilizowana) na dzisiaj prezentuje się mniej więcej tak

Od razu widać że poszliśmy (jak to zazwyczaj my) o duży krok dalej. Chcemy, na ile się da, uchronić zespoły deweloperskie i integracyjne od mozolnego zdobywania wiedzy o działaniu szyny, czy niskopoziomowego jej programowania. „Klu” rozwiązania to wprowadzenie pojęć wyższego rzędu: „komunikat”, „odbiorca”, „nadawca”, „proces”, „konfiguracja”, „zarządca”, oraz opracowanie zdefiniowanego i predefiniowanego schematu wdrażania i działania procesów na szynie. Wiele aspektów działania szyny będzie można „wyklikać” zamiast je implementować, zmniejszy to koszty powiększając korzyści. Mam nadzieję, że niedługo będę mógł napisać o pierwszym wdrożeniu naszej szyny, co z radością uczynię.