poniedziałek, 24 lutego 2014

EIP w oparciu o framework Apache Camel. Chapter 1


Poznaj swojego nowego przyjaciela.
Ma na imię Camel. To taki integration master. Silnik do budowy i obsługi zdefiniowanych tras. Pozwala projektantowi zadecydować kiedy wysłać i odebrać wiadomość, ustalić politykę procesowania, błędów, gwarancji dostarczenia czy ponawiania.
Dostarcza się warstwę abstrakcji, która przykrywa szczegóły protokołów i dostarcza obsługę popularnych formatów danych.

Integracja systemów to ciężka praca. Developer musi zmierzyć się z następującymi problemami :


- komunikacją systemów (wystawianiem i konsumpcją danych serwowanych przez zdefiniowane endpoint'y)

- transformacją komunikatów (tak aby jeden system mógł porozumieć się z drugim)

- manipulacją tras (czyli zmianą logiki działania, serwowania danych czy strategii transformacji oraz wyboru rodzajów i sposobów komunikacji po przez czynniki wewnętrzne  - uwarunkowania biznesowe)

- odpowiednie reakcję na zaistniałe błędy (zdefiniowanie polityki obsługi błędów )

Co dostajemy w zamian korzystając z systemów integracji jak Camel czy Spring Integration ?

- redukcje boilerplate code (nie musimy już programować obsługę JMS, SOAP, JDBC, socket-level I/O czy mechanizmów transformacji i konwersji jak np CSV, XML, JSON etc )

- jasność działania biznesu aplikacji. Posługujemy się wzorcami EIP, które są ogólnie skatalogowane i dobrze znane programistą implementującym logikę biznesową czy też integrację pomiędzy systemami.

- monitoring. To dostajemy out-of-the-box. Czyli wiemy ile komunikatów przeszło daną trasą ile wpadło do Dead letter queue etc

- redukcje popełnionych błędów. Stosujemy szablony i sprawdzone abstrakcję poparte setkami testów oraz działaniem produkcyjnych w wielu systemach.

- ponad 160 istniejących komponentów wśród nich znajdziemy takie jak np:
 File, JMS, PGP, SMTP, ZooKeeper, Facebook, Twitter, SAP, Nagios i wiele innych. 

Camel opiera się na na lekkim i lubianym modelu POJO, DSL, akceptuje definicję i konfigurację zarówno w javie, xml, scali czy groovy'm.
Posiada lekki core, automatyczną konwersje typów, wbudowane wsparcie testów, modularną budowę, zestawy wtyczek i komponentów ułatwiających integrację na różnych płaszczyznach.
Integrację z wieloma frameworkami jak np Spring, OSGi Blueprint etc

Koncepcja EIP jest prosta i czytelna i stąd jej ogromna potęga.

Wygląda to w skrócie następująco :

 nasłuchuj na zadanym endpointcie korzystając z JMS
     rozdziel wiadomość bazując na jakimś wrażeniu
             przetwórz wiadomość niezależnie i równolegle
                   z agreguj wynik w całość
    dostarcz przetworzoną wiadomość do końcowego klienta używając protokołu  SFTP i danego endpointu


Może inaczej. Jeśli jeszcze nie czujesz tej potęgi zalet systemów integracji to może mój przykład Cie przekona.

Wyobraź sobie, że masz dany zasób na który w dowolnych momentach wpadają wiadomości w formie plików XML. Twoim zadaniem jest konsumować te pliki, po przetworzeniu każdego z nich przenieść każdy z osobna do innej lokacji np /backup , rozdzielić wiadomości bazując na dostawcach i priorytetach. Wysłać powiadomienia o udanych transakcjach do klientów korzystając z SMTP  i równolegle dostarczyć wiadomość w formie pliku csv do magazynu sklepu w celu wysłania towaru do klienta. W przypadku błędnego pliku powiadomić po przez WS system dostarczający pliki do naszej lokacji czyli startowego endpointa.

Uffff. Sporo tego. Nie korzystając z Camela musimy uporać się z wieloma problemami. Każdy z nich z osobna możemy spieprzyć czytaj spierdolić :).
Czy będzie to przetwarzanie pliku XML, czy to wytwarzanie pliku CSV, wysyłka maila z szyfrowaniem załącznika, obsługa błędów, wystawienie WS, transformację wiadomości, obsługę operacji I/O. Jest tego naprawdę dużo.


Rozważmy np prosty endpoint file:/ czy sftp:/. , których zadaniem jest polling lokalnego zasobu.
Pisząc jedną linię kodu w Camelu równoważymy setki linii kodu, który musieli byśmy napisać a potem przetestować itd.
Stosując Camela nasz kod jest reużywalny i łatwy w testowaniu. Przy czym również bardzo prosty do zrozumienia przez drugiego programistę.

Używając Camela można to wszystko co opisałem wyżej zrobić na jednym ekranie monitora! Brzmi super! i tak też działa.

Ale po kolei:)

Generalnie możemy wyróżnić następujące typy integracji : (moje stare notatki)




 
Information Portals
Problem : Użytkownik końcowy musi mieć dostęp do wielu systemów aby otrzymać odpowiedź na zadane pytanie.
Przykład : sklep internetowy i system reprezentowany przez firmę kurierską monitorującą stan zadanej przesyłki.
Nie dość, że jesteśmy zalogowani w sklepie to czasem musimy zalogować się do systemy monitoringu firmy kurierskiej. Obecnie jest to rzadko spotykane, bo wystarcza nam w tym celu wygenerowany token.
Data Replication
Problem : Wiele heteregoniczych systemów potrzebuje dostępu do tych samych danych, tworzą bliźniacze magazyny danych.
Przykład : System  A, B i C korzysta z danych znajdujących się w tej samej fizycznej bazie. Rozwiązaniem jest replikacja danych na poziomie samej bazy lub np zastosowanie kolejek do transportowania danych między systemami
Shared Business Functions

Problem : W ten sam sposób wiele aplikacji przechowuje nadmiarowe dane, co aplikuje tendencją do redundancji funkcjonalności.


Przykład : Wiele systemów korzysta z NIP'u danego klienta, lub słownika kodów pocztowych. Można ujednolicić usługę poprzez wystawienie wspólnego API, co z kolei skutkuje tym, iż podobne usługi w heterogenicznych systemach znikną zastąpione klientami.
Service-Oriented Architectures

Problem : Wspólne funkcje biznesowe możemy realizować za pomocą dobrze zdefiniowanych usług. Sługi te są powszechnie dostępne i odpowiadają na żądania klientów. Usługi te muszą być na stałe zamontowane w infrastrukturze systemu, skatalogowane pod względem dostępnych funkcji. Każda usługa SOA musi opisywać swoją funkcję oraz sposób komunikacji z innymi usługami w tejże architekturze. Wszystkie usługi z katalogu usług muszą dostępne być w spójny sposób.
Tutaj może się zatrzeć różnica pomiędzy integracją a rozpowszechnianiem usługi. 
Distributed Business Processes

Problem : Jedna transakcja biznesowa może być rozprzestrzeniana pomiędzy wiele systemów. Często brakuje koordynatora dla takich zadań, który zarządza wykonaniem podobnych funkcji w wielu istniejących systemach.

Przykład : Rozmycie odpowiedzialności dla funkcji biznesowych jak i usług SOA
Business-to-Business Integration

Problem : Ujednolicenie protokołów komunikacji, formatu danych  oraz systemów bezpieczeństwa pomiędzy dostawcą a klientem usługi.


Przykład : Sklep internetowy - dostawca towaru, komunikacja pomiędzy partnerami biznesowymi.

Sposoby zdalnej komunikacji :
- RPC
- RMI
- REST
- WS
- COBRA
- JMS
- Remoting (spring http remoting etc)

Rozważmy najprostszy znany typ integracji to komunikacji TCP/IP ale ma ona następujące wady :

- Location - musimy zrobić hard-coded dla adresów fizycznych maszyn
- Time  - komponenty objęte obszarem komunikacji muszą być dostępne w tym samym czasie
- Data Format - listy parametrów i ich typu muszą się zgadzać po obu stronach
- bardziej tight coupling niż loose coupling


Na decyzję integracji mogą wpływać następujące czynniki : 

- Application coupling -  aplikacje powinny dążyć do minimalizacji wspólnych zależności

- Integration simplicity - należy dążyć do maksymalizacji prostoty integracji.
Minimalizować ilość kodu i  koszty utrzymania aplikacji.

- Integration technology - należy brać po uwagę użyte technologie, koszty z nimi związane oraz ewentualne problemy projektowe

- Data format - należy umożliwić wymianę danych pomiędzy systemami bazującymi na innych formatach danych czy protokołach. Należy tak projektować systemy integracji aby zamiana protokołu czy formatu była możliwie jak najprostsza i jak najmniej kosztowna.

- Data timeliness - integracja powinna brać pod uwagę minimalizację czasu pomiędzy udostępnieniem danych przez jedną z aplikacja a konsumpcją i ewentualną odpowiedzią przez drugą aplikację. Dane powinny być wymieniane w stosunkowo małych kawałkach, a nie w zbiorach dużych niepowiązanych elementów co może mieć impakt z przyszłą wydajnością systemu
Tip : Spring Batch
Opóźnienia (Latency in data sharing) powinny być uwzględnione w procesie projektowym, gdyż może skutkować to tym, że dane dane nie będą już aktualne, a integracja stanie się bardziej złożona.

- Data or functionality -  zintegrowane aplikacje mogą nie tylko dzielić ze sobą dane ale również dzielić funkcjonalność (SOA). Zdalne wywołanie funkcji jest zawsze trudniejsze i bardziej kosztowne niż wywołanie jej lokalnie - zawsze musi brać to pod uwagę, bo konsekwencje mogą być istotne.

- Asynchronicity - typowym podejście jest proces synchroniczny czyli klient czeka na odpowiedź serwera, jak już ją dostanie może kontynuować przetwarzanie danych. Takie podejście może stwarzać nie tylko problemy wydajnościowe ale także problemy związane z dostępnością. Np mogą wystąpić chwilowe problemy z siecią, dany zasób może być chwilowo niedostępny również z innych powodów. Zastosowanie mechanizmów asynchronicznych, gwarancji dostarczenia oraz ponawiania pomoże rozwiązać ten problem.

Sposoby integracji systemów : 

- File transfer - czyli wymiana plików :








Aplikacja produkuje pliki zawierające informację potrzebne do integracji. Druga aplikacja konsumuje je w określonych odstępach czasu albo przez ciągły monitoring (polling) zasobu. Następnie musi wziąć odpowiedzialność za transformowanie plików do spójnych czytelnych formatów.

   Features :
   - systemy budowane w różnym czasie - problem wyboru technologii
   - systemy budowane przez różnych ludzi, różne podejścia (preferencje)
   - wybór formatu pliku
   - dostępność pliku, periodyczność wytwarzania czy konsumncji

   Zalety :
   - uniwersalny mechanizm przechowywania danych, dostępny w każdym  systemie
   - nie potrzeba jest wiedza na temat wewnętrznej części aplikacji (jedynie warunki negocjacji integratorów systemów)
  - nie wymaga skomplikowanej konfiguracji jak np : MOM

  Wady : 
    - integracja zazwyczaj wymaga więcej pracy od dewelopera (nazewnictwo, parsowanie, transformacje, kopie zapasowe, polityka postępowania z plikami)
    - zastosowanie mechanizmów blokujących (jeśli plik nadpisywany jest strumieniowo, klient nie może go odczytać aż do skończenia pisania)
   - brak szybkiej synchronizacji
   - duże koszty przetwarzania i obsługi zasobów dyskowych (I/O)
   - walidacja i niespójność danych 
   - zachowanie izolacji między systemami kosztem aktualności danych. (Systemy nie nadążają za sobą, współpraca jest zbyt wolna)
  
 TIP : jeśli zależy Ci na umożliwieniu częstej wymiany małych ilości danych bardziej odpowiednie będzie użycie RPC lub Messaging.

- Shared database - wspólna baza danych













Features : 
  - wszystkie dane opierają się na tej samej bazie danych. Gwarancja spójności.
  - wiele formatów plików (File transfer) = wiele potencjalnych problemów
  - gdy aplikacja mu być dystrybuowana na wielu komputerach baza danych musi być również replikowana

Zalety :
  - lepsze walidacja i spójność danych niż w przypadku File Transfer
  - łatwiej wykryć i poprawić ewentualne rozbieżności w formatach danych

Wady :
  - opracowanie jednego jednolitego schematu dla wszystkich kontraktorów systemu
  - przechowuje dane razem kosztem sprzęgania.

  TIP : NOSQL = schema free

  - potencjalne przyczyny wąskich gardeł : locks
  - rozproszona baza danych z konfliktem (locking conflict) może stać się koszmarem jeśli chodzi o wydajność
  - baza danych zbyt odsłania struktury danych co kłóci się z ideą enkapsulacji, a taki kod jest trudniejszy w utrzymaniu.

TIP : Do umożliwienia częstej wymiany małych ilości danych przy użyciu jednego formatu na typ danych użyj RPC, w przypadku uniwersalnego formatu lepiej sprawdzi się Messaging.

- RPC - czyli wywołania zdalne










Features :
 - samo udostępnianie danych często nie wystarcza. Częste zmiany danych mogą prowadzić do poważnych zmian w różnych aplikacjach.
 - wywołanie funkcji w jednej aplikacji wraz z przekazaniem informacji jak te dane ma procesować
 - RPC , Corba , Remoting, RMI, WS, REST

Zalety : 
 - lepsze enkapsulacja niż w przypadku podejścia Shared database
 - każda aplikacja z osobna jest wstanie utrzymać integralność swoich danych
 - każda aplikacja może zmienić swoje dane wewnętrzne bez żadnego negatywnego wpływu na drugą aplikację.
 - wsparcie dla transakcji
 - użycie WS nie koliduje z regułami firewalla
 - eliminacja wspólnych dużych struktur danych, zmniejszenie sprzężenia pomiędzy systemami

Wady :
  - negocjowanie interfejsu z innymi systemami podlegającymi integracji
  - duże różnice w wydajności pomiędzy wywołaniem zdalnym a lokalnym
  - tight couple (ciasne wiązanie)
  - nieodporny na uszkodzenia lub chwilową niedostępność innego systemu

Tip : W celu częstej wymiany małych ilości informacji, bez żadnego narzutu na sprzężenie i obawy na wydajność lepiej sprawdzi się Messaging.

- Messaging - komunikacja systemów poprzez systemy kolejek (loose coupling)









Tworzenie kolejki :














Features : 
 - niezależny od platformy
 - niezależny od języka i systemu










 - Channels - wirtualne kanału przekazywania wiadomości zestawiane pomiędzy senderem a receiverem.

- Message - to atomowy pakiet danych serwowany przez channel. Składa się z nagłówka(header) i ciała (body)

















- Multi-step delivery - wykonanie działań mających na celu poprawne dostarczenie wiadomości do adresata. Np walidację czy transformację danych podczas wysyłki.

Routing - połączenie kanałów i procesów biznesowych w logiczną spójną całość.

Transformation - zmiana formatu danych tak aby zaakceptował go docelowy odbiorca

Endpoint - umowny punkt wejścia i wyjścia dla danego procesu routingu, definiujący określony protokół.

Pojęcia kluczowe w messagingu :

- broker (broker) – odpowiednik poczty
Zapewnia on dostarczenie wiadomości do określonego adresata . Klient nie musi posiadać żadnej wiedzy jak broker sobie z tym poradzi – to jest dla niego
przezroczyste.

- miejsce docelowe (destination) – rodzaj adresu pocztowego
Określają gdzie komunikat będzie odebrany, nie na tym kto go odbierze

Rozróżniamy dwa rodzaje miejsc docelowych :
- kolejki (Queue)
- tematy (Topic)



P2P - opis : 
Punkt-punkt czyli P2P (point-to-point) w przypadku kolejek
W modelu P2P każdy komunikat ma jednego dostawce i jednego odbiorcę
Broker umieszcza komunikat w kolejce. Odbiorca zgłasza się po komunikat
komunikat jest pobierany z kolejki i dostarczany odbiorcy.
Podczas dostarczania komunikat jest usuwany z kolejki stąd pewność, że trafi on tylko do jednego odbiorcy.
Komunikaty z kolejki mogą być przetwarzane przez dowolną liczbę odbiorców
Analogią takiego działania może być kolejka do kasy

Zastosowanie P2P :
 - klaster usług
 - load balancing – czyli równoważnie obciążenia na zasadzie pull, nie push
   Jeśli usługa jest nadmiernie przeciążona wystarczy dodać kilka nowych    instancji usług (MDB) odbierających komunikaty z danej kolejki

 - kosztowne czynności, których rezultatów nie musimy mieć od razu
 - komunikacja pozbawiona blokowania (asynchroniczność)
 - wysoka skalowalność
 - łatwa priorytyzacja
 - integracja
 - luźne sprzeżenia
 - większa wydajność przy słabym łączu
 - szeregowanie transakcji
 - routing
 - strategia Master-Slave

Sub-Pub : opis
Publikacja-Subskrypcja czyli (publish-subscribe) w przypadku tematów
W tym modelu komunikaty są wysyłane do tematów.
Wiele odbiorów nasłuchuje kanał jak w przypadku kolejek ale w modelu Pub-Sub wszyscy subskrybenci dostają kopie tematu.

Analogia : gazeta – prenumerata, czyli każdy kto zaprenumeruje daną gazetę
otrzymuję np. co tydzień identyczny egzemplarz
Zalety messaging'u: 
 - totalnie luźnie wiązanie
Luźne wiązanie + rozprężenie (loose coupling + decoupling) – klient nie musi wiedzieć nic o serwerze. Integracja różnych systemów napisanych w różnych technologiach. Klient nie jest uzależniony od konkretnego adresu usługi jak w przypadku komunikacji HTTP

 - mechanizm ponawiania

 - gwarancja dostarczenia (quaranteed delivery

 - mechanizm persystencji Trwałość komunikatu (durable)

 - odporny na uszkodzenia lub chwilową niedostępność danego systemu
Niezawodność (reliability) - klient nie jest uzależniony od dostępności zdalnej  usługi 

 - ogólna odporność (robustness)
 
 - obsługa asynchronicznych komunikatów - odpowiednia reakcja na problemy występujący w systemach rozproszonych.  
Asynchroniczność – klient nie czeka, aż usługa zostanie przetworzona (wydajność) czyli brak blokowania. Usługa typu file-and-forget.

 - mniej punktów awarii (fewer points of failure)

 - łatwa transformacja i routowanie wiadomości  np : XPath

 - brak wrażliwości na zmianę koncepcji czy interfejsu zdalnej usługi, dla klienta jest to nadal przezroczyste. (dobry przykład to WS czy REST)

 - koncentracja na danych zamiast wywołaniu metody jak w przypadku komunikacji RPC

Wady :
 - trudniejsza implementacja
 - trudniej testować i debugować


Mając podstawową wiedzę możemy powrócić do tematu czyli Apache Camel.
























Podstawowym obiektem Camela jest obiekt wymiany jakim jest Exchange Message.
Zawiera on właściwości w postaci  mapy<String,Object>, unikalny identyfikator wiadomości Exchange ID, Message Exchange Pattern w skrócie MEP, dwie wiadomości oraz ewentualne wyjątki.

InOnly—A one-way message (znaną też jako Event message). Czesto JMS wykorzystuje one-way messaging. Odpal i zapomij operacja jednokierunkowa.

InOut—A request-response message. Transport typu HTTP często bazuje na tego typu wiadomości gdzie żąda wyświetlenia strony ale musi i czeka na odpowiedź serwera. Żądanie-odpowiedź.

MEP określa czy użyć styl InOut, czy InOnly.

MEP to skrót określający wzorzec wymiany komunikatów. Jest to termin zaczerpnięty z nomenklatury SOA. Najbardziej znany przykład tego wzorca to 'żądanie-odpowiedź' - usługodawca wysyła komunikat-żądanie do usługi-dostarczyciela. Po poprawnym odebraniu komunikatu wysyła do jego nadawcy komunikat-odpowiedź w kierunku przeciwnym przez usługę dostarczyciela.
Więcej o wzorcu MEP czytaj w poście SOA czyli tutaj.

MEP to po prostu abstrakcyjny wzorzec interakcji pomiędzy dwiema usługami. Definiuje wymianę komunikatów pomiędzy nimi.

Exception - ewentualne błędy, które pojawią się podczas routingu wiadomości.

Processor jest to bazowy interfejs służący do przetwarzania wiadomości. Generalnie implementowany zawsze przez programistę.

Route - zestaw kroków zdefiniowanych przez programistę zaczynając od słowa kluczowego a zarazem Endpointu "from". Trasy są z reguły luźno powiązane i powinny być łatwe do przetestowania i użycia w innym miejscu systemu.
  
Trasy :
- zdecydują o dynamicznym zachowaniu serwera 
- pozwalają w elastyczny sposób dodać dodatkowe przetwarzanie
- powalają odseparować klienta od logiki serwera
- umożliwiają mockowanie procesów
- promują najlepsze praktyki projektowe
- mogą być wykorzystane w systemach typu ESB

Context - czyli ładowanie i definicja wszystkich komponentów, tras, konwerterów oraz ustawień potrzebnych aby wystartować proces Camela.












Component - biblioteka, która enkapsuluje komunikację, transport i zachowanie za wspólnym interfejsem zdefiniowanym przez Camela. Camel używa komponentów do produkcji bądź konsumpcji wiadomości.

Endpoint - może być potraktowany jako identyfikator źródła zasobów czy będzie to JMS, czy File jest to obojętne. Słowo kluczowe "from" - oznacza czytaj z , a słowo "to" - zapis , wyślij do.

Camel DSL - możemy użyć płynnych interfejsów :
 - Java DSL
 - Spring DSL
 - OSGI Bluepring XML DSL
 - Groovy DSL
 - Scala DSL

Każdy z DSL ma swoje wady i zalety ale o tym potem w następnym poście.
Poniżej obrazowy przekrój problemów oraz wybór odpowiedniego komponentu. (jako rozgrzewka przed następnymi postami z cyklu integracja)
źródło : http://www.eaipatterns.com/

Podsumowując: Dziś nauczyłeś się co to jest integracja. Jaką możesz wybrać strategię. Co to jest Camel ? - czyli  totalny wstęp. Jak wybrać i dobrać odpowiednie rozwiązanie integracyjne do Twoich potrzeb.
Dla mnie Camel to cudowne narzędzie. W wielu przypadkach pozwolił mi redukować kod i potencjalne problemy do minimum.
Kiedyś nie znałem wzorców integracji EIP oraz żadnego frameworka integracyjnego.
Jak dziś oglądam swój kod w, którym przeprowadzam integrację ręcznie - cóż wygląda pożal się Boże.
Wstydzę się go dzisiaj. Niestety wtedy jeszcze jakieś cztery czy pięć lat temu nie posiadałem takiej wiedzy i zapłaciłem wtedy duże frycowe. Napotkałem szereg problemów, napisałem dużo gównianego kodu. Chciałbym, żeby każdy kto przeczytał dzisiejszy wstęp do integracji nie popełnił mojego błędu i poszedł w kierunku Camela czy Spring Integration.
Co więcej zarówno Camel jak i Spring Intergration super integrują się z Spring Batch to bardzo ważne jak to robić pokaże w następnych postach z cyklu intergracja.


training in Camel part 1

Brak komentarzy:

Prześlij komentarz