środa, 4 czerwca 2014

Camel training - 1

Jakiś czas temu pisałem o sposobach integracji systemów na przykładzie EIP.
Dziś przybliżymy się temu bardziej.

Apache Camel to 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 140 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.

Camel charakteryzuje się :
 -  lekkim core,
 -  DSL
     - java
          Zalety :
                - elastyczność
                - współdzielenie przez wiele procesorów
                - często bardziej zwięzłe niż ich odpowiednik w xml
                - łatwość testowania w separacji
          Wady :
               - dla programistów nie znających javy mogą stanowić wyzwanie
               - trudniej zrozumieć zaawansowane konstrukcje oparte na wzorcach
               - może zacierać się różnica między procesowanie a przepływem  informacji
     - spring
          Zalety:
             - bardziej czytelny dla programistów wszelkiej maści
             - namespace daje duże ułatwienie
                - bardziej przenośny np import to Karaf
                - formatowalny
          Wady: 
              - często bardziej rozwlekły
              - mniej elastyczny niż odpowiednik DSL'a
                 - trudniej odseparować i zaprojektować odpowiednie testy
     - scala
     - groovy
 -  automatyczną konwersje typów,
 -  wbudowanym wsparcie testów,
 - modularną budowę,
 - zestawem wtyczek i komponentów ułatwiających integrację na różnych płaszczyznach.

Integruję się  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

Message - tutaj przechowywane są dane biorące udział w przebiegu tras.
Wiadomość :
  -  biegnie od wysyłającego do adresata.
  - składa się z :
        -  treści  (body) = (payload)
        -  nagłówka (header)  (Map<String,Object>) + posiada unikalną nazwę
        - opcjonalnie z załączników (attacgments).
        - flagę błędu (fault flag)
   - jest unikalna i posiada identyfikator w postaci Stringa.


Exchange - stanowi 'pojemnik' dla wiadomości podczas podróży po trasie.

Dzięki MEP możemy wyróżnić dwa typy wysyłania wiadomości :
 - Event Message (or one way) ustawiamy Message na InOnly
     (domyślnie dla   JMS, File czy SEDA)
 - Request Reply    ustawiamy Message na InOut

Składa się z : 

Exchange ID - unikalny identyfikator
MEP - przełącznik InOnly/InOut
Exception - jeśli wystąpi jakiś błąd w czasie trasy, wyjątek będzie ustawiony w tym polu
Properities - odpowiednik headers dla Message => Map<String,Object>
In message - wiadomość wejściowa - wymagane
Out message - opcjonalna - tylko dla trybu InOut

Więcej na temat MEP znajdziesz tutaj.

Camel context













Operacje jakie możemy przeprowadzić na kontekście Camela to : 
- zarejestrować słuchaczy którzy będą nas informować o cyklu życia zdarzeń
- określić strategie dla tras, stopowania kontekstu
- zarejestrować komponenty JMX
- oraz wiele innych ..

Compoments = komponenty Camela - wspomaganie i ułatwianie integracji
Automatycznie rejestrowanie poprzez dodanie jar'u do classpath'a

Endpoint - końcowe punkty dostępu , defniowane podczas tworzenia tras

Producer - umożliwia tworzenie i wysyłanie wiadomości

Consumer - odpowiada za przyjmowanie wiadomości

Event-driven consumer 
Słucha i przetwarza wiadomość aż ta nadejdzie. 
Jest nim zazwyczaj port TCP / IP lub kolejka JMS. Czeka na klienta poprzez  wysyłanie wiadomości na dany Endpoint. Gdy nadejdzie wiadomość, event-driven budzi się i wykonuje jakieś przetwarzanie dla tej wiadomość. Działa w sposób asynchroniczny.


Polling Consumer
W przeciwieństwie do event-driven consumera, ten rodzaj słuchacza cały czas odpytuje zasób czy przyszła jakaś wiadomość. Przykładem takiego działania może być komponent FTP lub File. Działa w sposób synchroniczny bo nie może podjąć więcej zasobów dopóki nie przetworzy aktualnego. 
Oparty jest na zasadzie schedulera z zadanym interwałem nasłuchu.



Przetwarzanie :
źródło : fusesource











Type converters - konwertowanie wiadomości treści wiadomości

Data formats - podłączamy obiekty transformujące pozwalające na marshalling z formatu binarnego lub tekstowego na oczekiwany format i odwrotnie.


Registry - definiuje strategie wyszukiwania i rejestracji beanów

Languages - wspomaganie dla wyrażeń regularnych ....(Predicate statement)
 np : ${in.body}  lub  ${in.header.productId} ,


Routes - trasy , logiczne przepływy informacji oraz strategie ich procesowania

Tworzenie trasy :
W java DSL musimy rozszerzyć  naszą klasę o  extends RouteBuilder.
Koniecznie też będzie przedefiniowanie metody :
public void configure() throws Exception w ten sposób powiemy co ma robić nasza trasa.

Następnie musimy naszą trasę zarejestrować w contekscie Camela czyli
CamelContext context = new DefaultCamelContext();
Jest to serce frameworka camel. Odpowiada za wątkowość, transakcyjność,  obsługę błędów, routing komunikatów i przekazywanie wiadomości.

context.addRoutes(new myRouteBuilder());

nasŧępnie musimy wystartować kontekst context.start();
Co warto dodać kontekst startuje w osobnym wątku więc nie blokuje mam nigdy głównego przepływu aplikacji.

Kiedy chcemy zakończyć działanie tras camela wywołamy context.stop();
To spowoduje zwolnienie zasobów i zastopowanie całego kontekstu.

Każdy trasa zaczyna się od słowa kluczowego from.
Endpoint powinien być w formacie opartym o standardy URI.

Routing engine konsumuje komunikaty z danego początkowego endpointa , następnie je konwertuje, filtruje czy przetwarza i ewentualnie zwraca wynik do drugiego endpointa, który to może zakończyć daną trasę lub być początkiem nowej.

Warto też zwrócić uwagę, że kontekst Camela żyje długo prawdopodobnie przez życie całej aplikacji.

Sposób rozpoczęcia życia kontekstu camela może zapoczątkować metoda main, w przypadku aplikacji Web jej kontekst, w przypadku aplikacji opartych na Springu będzie to jakiś rodzaj applicationContext.xml czy OSGI .

Podczas startu kontekstu Camela startują i rejestrują się w nim pozostałe komponenty, punkty dostępowe i aktywują trasy.

Camel context pozwala na (w czasie działania systemu):
  - dynamizm
  - startowanie tras
  - zatrzymywanie tras
  - usuwanie tras

Dodawanie nowych tras możliwe jest przed startem kontekstu lecz mogą być one potem zatrzymane i restartowane gdy kontekst już zacznie działać.

Aplikacja oparta na Camel Framework może działać jako samodzielny byt lub współpracować z kontererami Springa czy Apache Karaf.

 Przykładowy kod do posta: 

next ->

Brak komentarzy:

Prześlij komentarz