wtorek, 10 czerwca 2014

camel training - part 3 routing + simple component

Siła Camela tkwi także w jego komponentach.
Jest ich wiele. Są dobre, sprawdzone, re-używalne i solidne. Znacznie upraszczają proces developmentu oraz  integracji.
Standardowe kompomenty dodaje się łatwo poprzez dodanie ich do classpath. (auto-discover mechnism - jak to działa opisałem poniżej)


W praktyce wygląda to tak :

w przypadku gradle :

Component Scan = wyszukiwanie komponentów 

Możemy uzyskać to na dwa sposoby :
  - z użyciem camel contextScan
  - z użyciem Spring component-scan
  - z użyciem Spring jako rejestracja zwykłego beana.

Użycie komponentu: 

 - Można dodać komponent manualnie :
  -
Przykład :
Można zdać się na mechanizm auto wyszukiwania :


 -  META-INF/services/org/apache/camel/component

Ta praktyka jest bardzo popularna. Camel potrafi sobie zarejestrować komponent w runtime poprzez umieszczenie klasy komponentu w classpath oraz wskazanie komponentu tak jak to na obrazku poniżej.
Trzeba pamiętać iż nazwa pliku definiującego komponent musi mieć taką samą nazwę jak sam komponent. Możecie sobie prześledzić takie zachowanie w przypadku wszystkich dostępnych komponentów. W ten sposób również należy tworzyć swoje własne custom'owe komponenty - i to jest bardzo wygodne.


































 
Tip : Dobrą praktyką jest dzielenie plików xml na logiczne części. Dzięki czemu dostajemy bardziej przejrzysty kod oraz re-używalność plików oraz komponentów.


Direct component.

Często zachodzi potrzeba rozdzielenia trasy na kilka mniejszych logicznych części :
  - zakresy transakcji
  - obsługa błędów
  - testability
  - reuse (re-używalność)
  - simplicity (łatwość developmentu oraz zrozumienia działania)

Działanie : synchroniczne
Direct jest wyzwalany jakimś komunikatem. Czyli tak naprawdę jest konsumentem komunikatu (consumer) zainicjowanym do działania poprzez producer'a komunikatu.
Nazwa w postaci wzorca URI odseparowana ':' zawierająca jedynie znaki alfanumeryczne. 
Musi być unikalna w obrębię całego kontekstu camela (CamelContext).

SEDA (Staged Event Driven Architecture) component. 

Działanie i zastosowanie podobne jak w stosunku do Direct component z tą różnicą, że działa asynchronicznie. Tak naprawdę jest to implementacja BlockingQueue działają w pamięci.
Może być wykorzystywana jako zamiennik kolejki JMS. Pozwala to konsumować wiadomość za wiadomością nie czekając , że przejdą one cała trasę i processing. Dopiero gdy wiadomości będą prze-procesorowane zaczną wracać do początku trasy.

Pozwala to osiągnąć funkcjonalność Pub-Sub jeśli ustawimy multipleConsumers = true.

Zastosowanie : Dla obsługi długo wykonujących się zadań (long running task) (Nie blokuje tras)

 Przypomnę jeszcze raz bo to jest bardzo ważne :

 - one way message (InOnly) - (aka fire and forget) - wysyłający nie oczekuje odpowiedzi odbiorcy
 - request/reply (InOut) - wysyłający oczekuje na odpowiedź od odbiorcy

Obie wersje mamy dostępne za pomocą wzorca MEP
MEP : 
  - In dla one way message 
  - Out dla InOut message kiedy odpowiedź jest mandatory

Jeśli MEP jest ustawiony na InOnly , producent wkłada do SEDA komunikaty nie czekają na odpowiedź.

Jeśli MEP jest ustawiony na InOut producent będzie czekał aż poprzednia wiadomość zostanie przetworzona lub wystąpi timeout.


Producer (producent)
ProducerTemplate - to prosty sposób wysyłania wiadomości do Camelowego Endpointu. Działanie i koncepcja jest bardzo podobna ze znanych mechanizmów templates w Springu np JmsTemplate czy RestTemplate.
W obu przypadkach dostajemy wygodne API, które upraszcza nam w znacznym stopniu wywołania lub obsługę różnych mechanizmów, przy enkapsulacji logiki.
 Ważne jest to , że : 
 -  send method = InOnly style
 -  request method = InOut style
 Dla asynchronicznego wysyłania użyj asyncSendBody - odpowiedź za pomocą Future<?>

Przykład użycia : 

Consumer (konsumer)
ConsumerTemplate - tak jak w przypadku producera tym razem konsumujemy komunikat.

Pracuje tylko z trybem InOnly.

Przykład :

Routing  komunikatów :
 
Content-Based Router  - odpowiednik instrukcji switch lub if-else if w javie
Zastosowanie : Routing komunikatów do różnych i odpowiednich tras bądź zasobów
Działanie :  określa punkt przekierowania zasobów na podstawie contentu.
Poprzez content w tym przypadku rozumiem :
   - header
   - typ payload (body)
   - treść payload (body)

JAVA DSL :
Przykłady użycia :

TIP : Możemy użyć tutaj również polecanie end dla Java DSL oraz </stop> dla xml jeśli nie chcemy aby trasa była kontynuowana w danej gałęzi.

Message Filter - pozwala na filtrowanie wiadomości - decyduje, które wiadomości mogą być przekazane dalej
Zastosowanie : decydujesz czy dana wiadomość ma wypaść z trasy, wejść do innej gałęzi, etc. Odsiew niechcianych komunikatów.


Działanie : określa warunek na podstawie :
   - header
   - body
bazuje na interfejsie Predicate podobnie jak w przypadku Content-Based Routera.
Używa : Xpath, XQuery, SQL i Expression Language
Przykład :


Multicast -Wysyłanie tego samego komunikatu do różnych miejsc w celu innego procesowania komunikatu. 
Domyślnie komunikaty są przetwarzane sekwencyjne w pipe'ie.
Można włączyć przetwarzanie równoległe bez czekania na przetworzenie komunikatu w kolejnym węźle - parallel
Przykład :

XML :
Tip : Error handling - stopOnException()
Tip : Równoległe wysyłanie do procesowanie - .parallelProcessing()




Wire Tap - wysłanie kopii exchange do innej lokalizacji (trasy) bez impaktu na orginalną trasę wiadomości.

Zastosowanie : audyt, logowanie wiadomość jako całości
  - payload
  - header
  - properties

Dzięki wire tap możemy monitorować wiadomości, zapisywać je potem na konsole, do bazy danych wysyłać do zewnętrznego źródła np poprzez interfejs sieciowy

Uwaga : Domyślnie działamy na płytkiej kopii obiektu = ta sama referencja. Może skutkować do nieprzewidzianymi skutkami ubocznymi jeśli w trasie z wireTap będziemy manipulowali wiadomością. Wtedy wiadomość znajdująca się w głównej trasie procesu też ulegnie zmianie.
Na szczęście wireTap dostarcza  możliwość wykonania głębokiej kopii dzięki czemu obiekt będzie zachowywał się jak 'immutable' .





Pipes and Filters pattern = wspomaga projektanta podczas procesowania dużych tasków - rozbijając je na sekwencje czy mniejsze logiczne kawałki.


Filters - decydują które wiadomości mogą być przekazywane dalej w czasie tras

Pipes - tworzą logiczny ciąg procesów
Działanie w szeregu :
JAVA DSL :
Działanie równoległe :
Zastosowanie :
  - Wyzwalanie taska pociąga za sobą ciąg logicznych zdarzeń np : kodowanie + kompresja + szyfrowanie.
  - tworzy logiczny ciąg zdarzeń wyrażając jasno zamiary autora.
  - dzieli długie procesy na logiczne kawałki


Brak komentarzy:

Prześlij komentarz