niedziela, 29 czerwca 2014

Kod do treningu z EIP 25.06.2014

Cześć,
kod do treningu z EIP z 25.06 - 28.06 niedługo wrzucę na githuba.

Pomysł jest taki : będę wrzucał końcowe zadania ze swoich treningów tak aby też inni mogli się czegoś nauczyć jeśli tylko mają taką chęć. Szczegółowego opisu nie będę zamieszczał jedynie diagram tras i kod, oraz linki do użytych komponentów. Teraz nie wcale czasu ale niebawem ten post zostanie uzupełniony o kod i trasę. Zgodnie z tym co obiecałem na ostatnim szkoleniu.
Pozdr wszystkich :).
BTW, okazuje się, że chyba ja jestem taki tępy... gdyż niektórzy łapią ideę  Camela w mig :) mi zajęło to trochę czasu.....pociecha jest taka, że do wszystkiego dochodziłem sam :)




Potrzebne komponenty które użyliśmy :
file://
jms://
smtp://
timer://
cxf://
http://

- csv
- bindy
- jaxb
- json
- velocity

- Multicast
- Enricher
- Filter
- Content-Based Router
- Message Translator
- Splitter
- Aggregator
- Recipient List
- Wire Tap
- Dead Letter Queue
- throttler
- idempotent-consumer
- loadbalancer

Pełne zadanie opiszę też niebawem. Zamieszczę też diagram tras.
<!--opis-->

Pełne zadanie w skrócie wyglądało to tak : 
Dostajemy w dane miejsce zamapowane fizycznie plik płaski.
Musimy go przetworzyć, przesunąć do innego katalogu o zadanej nazwie i odpowiednio nazwać przeczytany już plik. Dane w postaci Person POJO wrzucamy do kolejki stosując też throttler oraz idempotent-consumer, który to
oczyszcza nasz zbiór z przypadkowych duplikatów.
Następnie przetwarzamy go w trasie zgodnie z podaną logiką:
agregujemy wyniki według stanowisk następnie powiadamiamy o tym kompetentne osoby poprzez email. Email korzysta z szablonów velocity.
Dekorujemy message o dane z rejestru dłużników poprzez użycie enrichera.
Definiujemy politykę błędów.

Obrobione dane możemy ciągnąć z bazy za pomocą REST'a lub wystawionego WS.

Kod będzie w formie Java DSL oraz camel xml. Stary kod narazie usunąłem gdyż nie zadowalał mnie jakościowo.


Proszę o chwilę cierpliwości .....

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


piątek, 6 czerwca 2014

Camel training : integration solutions

Wsparcie dla  integracji systemów (forma prezentacji ;)).

Dla tych którzy wiedzą co jest na rysunku wszystko będzie już jasne - to PowerCommander. Jeśli jeździsz na motocyklu możesz to urządzenia zastosować.
 - Co ono robi ?
 - Zmienia mapę zapłonu dodając więcej HP dla Twojego bike'a.
Niekoniecznie będzie więcej ciągnął wachy....chociaż z reguły tak może być :)
Intencją jest taka : zmieniam coś i dostaje coś w zamian. Mogę użyć rozwiązań asynchronicznych ale muszę liczyć się z konsekwencjami i zyskami takiej decyzji. Asynchroniczność kojarzy się z Jms.





Apache Camel świetnie z tego korzysta.
Masz do dyspozycji dwa rozwiązania : SEDA oraz Jms. Który wybrać ? o tym w następnym poście. Teraz przybliżę trochę ideę kolejek..niech one zostaną Twoim PowerCommanderem rozwiązania.


 
Wsparcie dla  integracji systemów (forma prezentacji ;)).

Usługi synchroniczne :
- RMI
- Hessian
- Burlap
- HttpInvoker
- WS* (istnieje możliwość asynchroniczności)

- REST (istnieje możliwość asynchroniczności )


Charakterystyka :

Klient kontaktuje się bezpośrednio ze zdalną usługą i oczekuje na zakończenie zdalnej procedury, względnie przetworzenie zdalnych wyników


Klient nie może kontynuować działania dopóki metoda się nie zakończy nawet jeśli metoda ta nie zwraca żadnego wyniku.
Takie zachowanie może w pewnych sytuacjach powodować spadek wydajności całego systemu.


JMS - właściwości

    - Usługę JMS możemy traktować jako tradycyjną pocztę, skrzynkę mailową

   - Konsument i producent nie należą do tej samej transakcji

    - Reply-Request – czyli wykorzystanie JMSCorrelationID oraz JMSReplyTo


    - DeadLetterQueue


Zalety : 

Asynchroniczność – klient nie czeka , aż usługa zostanie przetworzona (wydajność) czyli brak blokowania . Usługa typu file-and-forget.

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


Niezawodność (reliability) - klient nie jest uzależniony od dostępności zdalnej usługi


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)


Gwarancja dostarczenia (quaranteed delivery)


Trwałość komunikatu (durable)


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


Mniej punktów awarii (fewer points of failure)


Ogólna odporność (robustness)


Pojęcia kluczowe:
 - 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)

Komunikacja P2P

Punkt-punkt (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

Charakterystyka : 
 Wysyłanie :
   - Fire and Forget
   - Request-Reply
 Odbieranie : 
   -Pull


Przykładowe 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ść)
 - Łatwo wykryć problemy związane z wydajnością oraz łatwo temu  przeciwdziałać – wysoka skalowalność
- Łatwa priorytyzacja
- Integracja
- Luźne sprzeżenia
- Większa wydajność przy słabym łączu
- Szeregowanie transakcji
- Routing
- Strategia Master-Slave

 


Komunikacja (Pub-Sub)
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.

Charakterystyka : 
  - kopie wiadomości są dostarczane do wszystkich zainteresowanych
  - nie ma pewności że każdy odbierze wiadomość
  - broadcasting
Wysyłanie : 
 - Fire and forget
Odbieranie : 
 - Push





Rodzaje wiadomości :

 - BytesMessage (stream of bytes)
 - ObjectMessage (Serializable)
 - TextMessage (String)
 - StreamMessage (stream primitive values)
 - MapMessage (key-value pairs)


Dodatkowo wiadomości mogą mieć nagłówki

Schemat nagłówka :

JMSDestination (send or publish method)

JMSDeliveryMode (send or publish method)  

 - (pesistent(default mode)/nonpersistence)
 - kompromis pomiędzy wyborem między reliability vs performance
 - Persistence Mode gwarantuje Once and only once delivery

JMSExpiration (send or publish method) czas po którym komunikat wygaśnie

 - expiration_time = current_time + timeToLive
 - //MessageProducer.setTimeToLive()

JMSPriority (send or publish method) 10 poziomów ważności od 0 do 9 - prioryteryzacja

  - 0 - 4 =  normal priority
  - 5 - 9 = expedited priority

JMSMessageID (send or publish method)


JMSTimeStamp (send or publish method) - czas wysłania komunikatu  tworzony przez producenta komunikatu


JMSCorrelationID (client)- skojarzenie bieżącej wiadomości z  poprzednią wiadomościa (for example : reply-request pattern)


JMSReplyTo (client) - określnie gdzie musi trafić odpowiedź na jakąś wiadomość (request/reply) - kolejka tymczasowa....


JMSType  (client) - pole zależy od vendora


JMSRedelivered (JMS Provider)


JMSMessageID - unikalna wartość dla każdej wiadomość nadana przez providera Jms


Rodzaje błędów :
- IllegalStateException
- InvalidClientIDException
- InvalidDestinationException
- InvalidSelectorException
- JmsSecurityException
- MessageEOFException
- MessageFormatException
- MessageNotReadableException
- MessageNotWriteableException
- ResourceAllocationException
- TransactionInProgressException
- TransactionRolledBackException


Przykładowy Broker - ActiveMQ

Przestrzeń nazw dedykowana dla ActiveMQ czyli amq (namespace dla spring)
Definicja fabryki połączeń – ActiveMqConnectionFactory
Definicja miejsca docelowego  - ActiveMQQueue lub ActiveMQTopic
Definicja JMSTempate – wstrzyknięcie fabryki połączeń
Definicja odbiorcy komunikatów – MDB czyli jms:listener
Opcjonalnie definicja :
 - JMX
- Ponowienia
- Trwałości
- Pobranie z JNDI
- Embedded ActiveMq

- ramy pamięci operacyjnej
- loadbalaning
- HA

Przykład konfiguracji : 


Spring JmsTemplate :
Interesuje nas tylko API JMS, każda implementacja brokera może być inna.

Stosujemy podejście analogiczne do innych szablonów springowych jak :
JDBCTemplate, HibernateTemplate i teraz JMSTemplate


JmsTemplate to odpowiedź Springa na boilerplate code czyli :
- tworzenie połączenia
- uzyskiwaniem sesji
- wysyłką komunikatów
- odbiorem komunikatów
- obsługa wyjątku JmsException → konwersja na jeden z niekontrolowalnych wyjątków Springa


Schemat przejścia :
ConnectionFactory->Connection->Session->MessageProducer->send


Zadania programisty to : generowanie nowych komunikatów + przetwarzanie otrzymanych


JmsTemplate jest bezpieczny wątkowo (thread-safe)


JmsTemplate  - Wysyła i odbiera wiadomości synchronicznie

Message Listener Container – odbiera wiadomości asynchronicznie (MDB)


ConnectionFactory

- SingleConnectionFactory
- CachingConnectionFactory


Tworzenie i usuwanie połączeń jest kosztowne.
Tworzymy więc grupę połączeń, którą nigdy nie zamykamy - tzn polling
PooledConnectionFactory jest analogią ActiveMQ doCachingConnectionFactory.


Bazuje na SingleConnectionFactory ale ignoruje wywołania Connection.close()
Zapewnia cache dla JmsSession i MessegeProduceres
Domyślnie tylko jedna sesja jest cached, ale można zmienić to zachowanie



JMS Selectors

Pozwala klientowi filtrować wiadomości.
Filtrowanie opiera się jedynie na nagłówkach (headers) nie na wiadomości (payload)

Przykład:

Zalety :
- potężne narzędzie filtrowania
- można zastosować do każdej wiadomości przez co eliminujemy niepotrzebne obciążenie.

Hint : Camel operacje na Selektorach !! - pierwsza klasa :)

Xpath selectors - filtrowanie po payload - Camel feature :)


Potwierdzenia odbioru : 
  AUTO_ACKNOWLEDGE - automatyczne potwierdzenie
  DUPS_OK_ACKNOWLEDGE - odbiór jest potwierdzany automatycznie ale mogą wystąpić duplikaty wiadomości
CLIENT_ACKNOWLEDGE - klient sam potwierdza odbiór



Bazując na activeMq mamy do dyspozycji różne protokoły oraz ustawienia:


Przykłady zastosowań Jms :
    - Wysyłka maili
    - Powiadomienia
    - Monitoring
    - Chat
    - rozpraszanie obciążenia
    - Operacje typu batch np. :
           - przetwarzanie zamówień
           - akceptacja zamówień
           - wysyłka zamówień
           - sprawdzanie stanu magazynu
           - analiza oszustwa

Kiedy zostajemy przy synchroniczności : 

  - przerost formy nad treścią
  - Oczekujemy wyniku
  - Nie mamy pewności powodzenia operacji
  - Stawiamy na łatwość debugowania oraz testowania
  - Kiedy operacja jest częścią większej transakcji lub stosujemy Extended Transaction Context



Podsumowanie: Szybki wgląd w koncepcje kolejek i możliwych zastosowań w integracji systemów. Tyle :)

next ->

czwartek, 5 czerwca 2014

introduce to spring security

Zabezpieczenia aplikacji.... Temat rzeka, problemy, decyzje projektowe, frameworki, rozwiązania.

Istnieje wiele różnych sposobów aby zabezpieczyć dobrze aplikację czy to aplikację Web opartą na URL'elach czy desktopową czy inną dowolnej maści.
Standard korporacyjny dostarcza nam dwa rozwiązania JAAS z J2EE oraz Spring Security ze Spring Enterprise.
Istnieją też inne możliwości jak open source Apache Shiro etc. Wybór należy do Ciebie, w każdym razie warto poczytać sobie o tych rozwiązaniach oraz sposobach ataku i obrony (OWASP) aby mieć lepszy przegląd sytuacji i dokonać trafnego wyboru. Ale tak czy inaczej w 90% będą to rozwiązania oparte na Spring Security.


Jego wszechestronność i dojrzałość plasują dają mu w tym momencie niekwestionowaną pozycję lidera.

Wstęp teoretyczny:

Mamy kilka sposób uwierzytelniania : 
basic authentication - serwer podaje nam formularz logowania z polami login + password. Nie musimy tworzyć strony logowania.
-Form-based authentication - uwierzytelnianie oparte na formularzu użytkownika
- Digest-based authentication - dane użytkownika są zahashowane stosownym algorytmem
- Certificate-based authentication - klient i serwer określają swoją tożsamość w oparciu o wygenerowany certyfikat. Komunikacja na łączu następuje w sposób szyfrowany po przez  SSL.



Historia :
2003 - Acegi Security - początek sagi
2008 - Acegi wchłonięte przez Spring - początek Spring Security


Spring Security to :
  - wszechstronność metod autoryzacji i autentykacji
  - zabezpieczenie przez atakami  (OWASP top ten)
  - integracja ze Spring MVC i Servlet API 3 i 3.1
  - w wersji 3.2 wsparcie dla javaConfig
  - zabezpiecznie przed CRFS, session fixation, clickjacking
  - przenośność rozwiązania
  - dojrzałość
  - pewność
  - integracja z różnymi protokołami i rozwiązaniami jak :
     - openID
     - OAuth
     - LDAP
     - SSO (CAS)
     -  RMI , HttpInvoker
     - JAAS
     - Kerberos
     - HTTP X.509
     - i wiele innych

najprostsza konfiguracja (maven) :
W gradle jeszcze prościej :


Teraz skład Spring Security : 
 - Core spring-security-core -> auth i access-control, remoting support etc
   - ogólnie jak to 'core' jest niezbędny do działania czegokolwiek w spring security framework. Zapewnia zabezpiecznie dla aplikacji standalone, zdalnych klientów, i metod biznesowych czy JDBC oraz obsługę kryptografii (Crypto)

 - WEB  spring-security-web - zawiera filtry, które możemy modelować w łańcuch  (Chain of responsiblity pattern) oraz integracje z Servlet API i URL-based access-control

- Config spring-security-config - zawiera Xml namespace dla wygodnej konfiguracji z poziomu XML znanej ze Springa oraz JavaConfig support

- LDAP - spring-security-ldap - autoryzacja oparta na protokole LDAP

- ACL - spring-security-acl - autoryzacja oparta na poziomie dostępu do obiektów domenowych. Znamy takie podejście z systemów Linux czyli kto i w jakim stopniu ma dostęp do zasobu.

- CAS - spring-security-cas - integracje z systemami SSO.

- OpenID - spring-security-openid - wsparcie dla protokołu openID. Autoryzacja użytkownika po przez zewnętrzne serwery OpenID np Google.

Wstęp do konfiguracji.
Spring Security jeśli chodzi o zabezpieczenie warstwy Web to tak naprawdę zbiór filtrów połączonych w łańcuch. Wszystko zostało stworzone tak aby zapewnić jak największą elastyczność rozwiązania a co za tym idzię konfigurowalność i moim zdaniem to jest największa siła SpringSecurity.

1. Dodaj zależność Spring Security do projektu
   - podstawa to : spring-security-core i w przypadku projektu Web spring-security-web oraz dla Twojej wygody spring-security-config.
Jeśli używasz JSP pewnie przyda Ci się spring-taglibs - dostajesz tagi dzięki,  którym Twój widok wygląda nieco lepiej i prościej go stworzysz w domenie security.

  Tip : Użyj Gradle - przekonasz się z czasem, że warto.
  Tip : extend'uj commons-logging - użyj logback.

 2. Web. Zarejestruj Security Filter w web.xml.
  

Tip : Kolejność filtrów jest ważna - jeśli o tym nie wiedziałeś to już wiesz;)

Następna sprawa to użycje javaConfig zamiast web.xml.
Jeśli używasz Servlet API w specyfikacji powyżej 3.0 włącznie nie musisz definiować web.xml. Nie jest już on obligatoryjny.

Tip : Jeśli używasz Xml czy JavaConfig wyekstraktuj kod związany z security do innego zasobu.

3. Skonfiguruj kontekst według własnej potrzeby
kontext z xml
kontext z javaConfig

4. Skonfiguruj minimum tego co na początku potrzebujesz + stwórz formę do logowania.

Tip : Stoworzenie formularza nie jest obligatoryjne ponieważ SpringSecurity potrafi wygenerować swój własny prosty formularz.

Co jest ważne a wynika z konfiguracji XML'a :

1. Formularz do logowania stworzony jest przez użytkonika i zmapowany pod URL : /welcome i to jest nasz główny punkt dostępowy

2. W przypadku błędu system wykorzysta ponownie nasz formularz lecz tym razem z paremetrem error -> /welcome?error=true
Błędem może być na ten czas wszystko. SpringSecurity sprytnie sobie przetłumaczy dany błąd na wyjątek, a my musimy podczepić i18n z odpowiednim komunikatem lub wykorzystać opisy błędów dostarczone ze springSecurity.
Tip : możesz wymusić HTTPS na danym punkcie dostępowym przez użycie requires-channel .

Tip : Ważne jest aby akcja logowania /j_spring_security_check przebiegała po kanale szyfrowanym najlepiej jeszcze POST'em. Uchroni Cię to przed podsłuchaniem hasła na linii.
URL /j_spring_security_check - to standardowy URL służący do autentykacji przez Web

Tip : _username oraz  j_password to standard SpringSecurity podczas budowania formy lub obsługi żadania pamiętaj o tym.


3. Wylogowanie :  logout-url="/logout" - definiujemy zasób URL na którym nastąpi akcja wylogowania.

TIP: Używaj handlerów. Zostały stworzone aby tam defiować dane zachowania jak np po wylogowaniu zmiana statusu w bazie danych.
(przykład handler użyty podczas wylogowania z aplikacji : success-handler-ref="logoutHandler")

4. Opis reguł bezpieczeństwa :
     np : /secure/** - dostępna tylko dla użytkowników który przeszli autentykacje.
     Czyli definiujesz kto z jaką rolą ma dostęp do danego zasobu URL.
  

Modele :
  - ACL  - drobnoziarnisty. Można definiować zachowania dla każdego obiektu dziedzinowego bardzo precyzyjnie. Traktuj jako macież zachowań.
Uwaga : model  może okazać się trudny do zarządzania jeśli wystąpi mnogość obiektów i czy rodzajów dostępów.

 - oparty na rolach : ROLE VOTER
   Łatwy prosty i przyjemny.

- oparty na rolach 'biznesowych'. Musisz sam oprogramować dane przypadki stosując strategie voterów.


Tip : Informacje o aktualnie zalogowanym użytkowniku dobrze opakować w tools'a.

cdn oraz uzupełnienie posta niebawem

Introduce to Spring Framework - basic knowlegde..

Po raz pierwszy spotkałem się ze Springiem w 2005 roku. Wtedy używałem wersji 1.2. Na samym początku nie czułem bardzo zalet jakie oferował on programiście. Po prostu wiedziałem, że można definiować beany i ich zachowanie w xml'ach, dzięki czemu jakiś kontener w przypadku wyraźnej potrzeby odpowiednio wstrzeli daną implementację bazując na interfejsie. Dla mnie to był fajny koncept ale nic poza tym. Czułem jedynie zaletę wynikającą z loose coupling, wspomaganie dla high cohesion i ogólnego testability. Tyle.....
Z biegiem czasu poznałem Spring MVC i od razu poczułem, żę Struts musi odejść do lamusa. Potem doceniłem warstwę abstrakcji dla DAO, wsparcie dla Hibernate, Spring templates itd.

 Spring to :
  - programowanie na interfejsach
  - proxy
  - aop
  - templates (RestTemplate,JmsTemplate,JDBCTemplate etc)
  - udostępnienie przejrzystego API
  - wzorzec DI
  - lekkie podejście do architektury oparte na zwykłym POJO

Pozwala :
 - uprościć proces wytwarzania oprogramowania
 - zwiększyć testowalność
 - izolacja API od złożonego kodu
 -  programowanie deklaratywne
 - modularność




Obsługa : 

- AOP -> Spring AOP, AspectJ
  (hermetyzacja zadań, problemy przekrojowe)
  przykład wykorzystania to :
        - logowanie,
        - cache,
        - transactions,
        - security
        - etc

Zalety :
  - zwiększenie modularności
  - zwiększenie możliwości tworzenie elementów wielokrotnego użytku czyli nie powielamy kodu
  - brak zaśmiecania kodu biznesowego kodem technicznym

Wady :
  - zwiększenie złożoności programu
  - kod może być nie do końca przejrzysty i zrozumiały
  - trudniej debugować kod oparty na dynamicznych proxy


- dostęp do danych oraz integracja
   - upraszcza dostęp do danych (eliminacja boilerplate code)
     (JDBC template operuje już na wyrażeniach lamba od Spring 4)
    - standaryzuje obsługę wyjątków
   - obsługuje fabryki sesji
    -  pule połączeń
    - wspiera ORM
    - OXM (Castor, JAXB, JiBX, XmlBeans, XStream)
    - JMS

- MVC
  - otwarta furtka dla Struts, JSF, Velocity, FreeMarker czy wreście mój ulubiony ThymeLeaf
 
TIP : Zawsze rozważ użycie ThymeLeaf  aby Twój development części frontend był sprawniejszy niż dotąd. Możliwość projektowania oraz implementowania widoków w całkowitej separacji od projektu. W JSP było niemożliwe z uwagi na tagi.

TIP : JSP jest już deprecated od wersji J2EE 6 więc.....

- Testowanie 
 - wsparcie dla JUnit, TestNg czy Mockito.

Tip : Testowanie nigdy nie było łatwiejsze. Spring wymusza większą modularność , oraz dostarcza IoC dzięki temu można przetestować dosłownie każdy kawałek kodu

Jak działa Spring ?  To proste  (rys poniżej):
    - POJO + konfiguracja
    - kontener DI (luźne wiązania między komponentami)

















Ważne jest to, iż kod pisany w Springu nie uzależnia nas od jego API.
Co to znaczy ? - To, że taki kod możemy użyć w innym rozwiązaniu czy zrębie programowym. Co najwyżej musimy czasem zastosować jaką adnotację ale to tyle. Konfiguracja i zachowanie beanów są doskonale odseparowane od kodu biznesowego aplikacji. To wielka zaleta.


Mamy możliwość zdefiniować kontekst na kilka sposobów :
 - używając XML
 - używając adnotacji (Spring 2.5)
 - używając javaConfig (java-based configuration) (Spring 3.0)
 - stosując podejście hybrydowe

Podejście oparte na XML:


Charakterystyka : 
    - <beans/>
    - namespaces
    - ClassPathXmlApplicationContext({context.xml}) - > rejestracja usługi

Dobre praktyki :
  - w nazwach namespaces nie używaj wersji. Uniezależnisz się w ten sposób od danej wersji.
  - rozdzielaj pliki konfiguracyjne w przemyślany sposób np funkcjonalność aop umieść w aop.xml,
    funkcjonalność cache w cache.xml , dostęp do danych w spring-data.xml  itd

Tip :  ścieżka do pliku z konfiguracją może znajdować się z odrębnej lokalizacji plikowej : 'file:/etc/config/personalBlog/services.xml' lub po prostu należeć do classpath projektu 'classpath:repository.xml'

- zawsze starać posiłkować się odpowiednim namespaces
- zawsze gdzie tylko to możliwe staraj się parametryzować kontekst poprzez placeholders -> ${}
- wszystkie konfiguracje staraj się trzymać w plikach properties czy yaml  tak aby nie zachodziła potrzeba modyfikacji xml'a

TIP : yaml - > bardziej oszczędny format dla properties

Zalety :
   - dobra czytelność
   - kod nie jest zależny od Springa / konfiguracja w oddzielnych plikach xml
   - pozwala na separację logiczną (SoC).

Wady:
  - verbosity
  - namespace zamknięty na rozszerzenia
  - trudno stworzyć swój własny namespace
  - not type-safe (brak bezpieczeństwa typu)

Użycie : 
 
 
Podejście oparte na Spring JavaConfig
   Charakterystyka : 
       - @Configuration - </>
       - @Bean    -> <bean/>
       - @Import -> <import/>
       AnnotationConfigApplicationContext - > rejestracja usługi
       - @AnnotationDrivenConfig -> enable the @Autowired
       - @ImportXml("classpath:cache.xml") - > import config based on xml
       - @ComponentScan -> <context-component-scan/> 
       - @EnableJpaRepositories -> <jpa:repositories base-package='{}'/>
       - @EnableWecMvc -> <mvc:annotation-driven/>
       - @EnableTransactionManagement -> <tx:annotation-driven/>
       - @PropertySource ->  <context:property-placeholder location='{}'/> 
       - @EnableAspectJAutoProxy -> <aop:aspectj-autoproxy/>
       - @EnableLoadTimeWeaving -> <context:load-time-weaver/>
       - @EnableMBeanExport -> <context:mbean-export/>
       - @EnableAsync -> <task:annotation-driven/>
       - @EnableCaching -> <cache:annotation-driven/> 

Przykład :  

Zalety : 
  - pełna programowa kontrola
  - wsparcie dla OO
  - integracja z innymi stylami wstrzeliwania zależności 
  - od Spring 3.0 wbudowana w core
  - bardziej odporna na błędy (już w czasie kompilacji) 
  - wsparcie refaktoringu ze strony IDE 
  - autocomplete IDE feature

Wady : 
   - czasem bardziej verbosity niż podejście XML
   - może wydawać się trudniejsza do zrozumienia niż standard XML
   - uzależnia kod od Springa

Podejście oparte na @Annotation

  Charakterystyka : 
      - @Component / @Repository / @Service / @Controller etc
      - @Autowired / @Inject / @Resource etc
       @Repository - > added  PersistenceExceptionTranslator functionality
      - @Value("${nazwa_property}") - wstrzyknięcie property

    
Zalety : 
  - łatwo można tworzyć swoje zachowania
  - eliminacja XML'a
  - łatwo zrozumieć kod i jego działanie

Wady : 
  - uzależnienie kod od Springa

Spring              ->            java.inject.*
@Autowired     ->            @Inject
@Component   ->            @Named
@Scope            ->            @Scope -> @Singleton
@Qualifier        ->            @Qualifier , @Named
        


WebApplicationIntializer - > eliminuje potrzebę użycia web.xml w specyfikacji Servlet API 3.0 w górę.




Powoływanie do życia beanu możemy uzyskać  przez :
 - wywołanie jego konstruktora
 - zastosowanie static method factory (Zastąp konstruktory statycznymi metodami factory)

 - zastosowanie factory method

Dependency injection osiągniemy głównie przez :
  - użycie settera
  - użycie konstruktora  

Tip : Użycie constructor injection zapobiega występowaniu cyklicznych zależności.

Tip : c-namespace dla konstruktora

Tip : Jeśli jakaś zależność jest obligatoryjna podczas tworzenia bean'a zastosuj wstrzyknięcie przez konstruktor, dzięki czemu będziesz miał pewność co do kolejności inicjalizacji grafu beanów oraz pokażesz swoje intencje w kodzie.

Tip : użyj @Required przy setterze jeśli zależność jest obligatoryjna do zbudowania zależności

Tip :  jeśli zależność nie jest obligatoryjna możesz użyć @Autowired(required=false)


Dla wczesnej inicjalizacji komponentu lub czyszczenia zasobów użyj :
  - destroy-method="{close}" 
  - init-method="{init}"

Init & Destroy
w przypadku xml  skorzystać z namespaces i opisać lepiej zachowanie beana:

  init-method="openResource" destroy-method="closeResource"

lub wykorzystując anotacje  @PostConstruct i @PreDestroy

lub  wykorzystując interfejsy

   - InitializingBean
   - DisposableBean

Referencje : 
  - do innego beana : <ref bean="someBean"/>
  - @Autowired Bean bean


Cykl życia bean : 
1.BeanNameAware
2.BeanClassLoaderAware
3.BeanFactoryAware
4.ResourceLoaderAware
5.ApplicationEventPublisherAware
6.MessageSourceAware
7. AplicationContextAware
8.ServletContextAware (web)
9.PostProcessBeforeIntialization
10.InitializationBean
11.PostProcessAfterInitialization



źródło  : khoaphamtechnology.wordpress.com



@Lazy - odracza inicjalizacje bean'a do możliwe jak najbardziej kiedy faktycznie jest od niezbędny

@DependsOn - mówi kontenerowi springa po prostu: "czekaj ten bean wymaga do działania innego beana więc zbuduj bean zależnego na samym początku"

@Primary - daje pierwszeństwo dla bean oznaczonego tą annotacją podczas procesu wstrzeliwania zależności


@Lazy, @DependsOn i @Primary mają swój odpowiednik w XML.


ApplicationEventPublisherAware - rejestrowanie eventów Springowych

Event-based communication between beans = observator pattern in Spring
  - bean dziedziczy po ApplicationEvent
  - publikator wiadomości implementuje  ApplicationEventPublisherAware
  - zainteresowany zdarzeniem implementuje generyczny ApplicationListener


Spring Profile : (czyli tworzenie zachować w zależności od .... * lepsza wersja to @Conditional dostępny w Spring 4. - > podstawa działania Spring Boot)

Sposób programowy:

Sposób JVM :

     -Dspring.profiles.activate=first

Sposób deklaratywny z web.xml:

Sposób z testów :

Spring profile

środa, 4 czerwca 2014

Microservices based on Spring Boot

Microservices - zorientowany na pojedyńcze zadanie. Zaletę tego podejścia docenili tacy giganci jak Google czy Amazon.
W odróżnieniu od architektury monolitycznej microservices preferują podejście małych zespołów, małych funkcjonalności wysokiej dostępności oraz skalowalności.

Jak można scharakteryzować microservices :
  - małą autonomiczną aplikację
  - zorientowaną na pojedyńcze zadanie
  - luźno połączoną z pozostałymi modułami
  - możliwie minimalną liczbę linii kodu
  - prawdopodobnie łatwiejszą do zrozumienia przez nową osobę w zespole
  - skalowaną na żądanie
  - zorientowaną na implementację przez mały zwinny zespół
  - bardzo podobne podejście do SOA z tą różnicą że mniej skomercjalizowane
  - agile , scrum oriented
  - bezbolesne wprowadzanie zmian
  - na ogół łatwiejsze wdrożenia


Wady : 
  - złożona integracja
  - potencjalny problem z rozproszonymi transakcjami (sharding)
  - testowanie integracyjne wielu odrębnych modułów
  
Zalety : 
   - rozmiar
   - zrozumienie domeny i problemu (skupienie się na potrzebach biznesu)
   - szybsze wytwarzanie (niezależne zespoły)
   - szybsze wdrożenia (rozmiar + problem + team + złożoność)
   - lepsza izolacja błędu
   - HA
   - skalowalność
   - niezależność
   - łatwiej wytwarzać czy przepisać na bardziej odpowiednią technologie.
   - idempotentność
   - wdrażanie na chmurze
   
  

Architektura monolityczna to standardowe podejście, które pewnie dobrze znasz z autopsji. Tak programuje i wytwarza większość firm i programistów.

Mamy jeden ear czy war i kilka jarów. To dobry pomysł i duże ułatwienie. Stosujemy pewnie mavena lub gradle w ten sposób zapewniając modułowość aplikacji. Spring zapewni luźne wiązania oraz DI i powstanie  całkiem solidna aplikacja. Kłopot z tym, że czasem ta aplikacja może przekroczyć swoją masę krytyczną .... znasz astronomię i fizykę. Wtedy wszystko się zapadnie i zostanie dziura tyle, że czarna.

Nowi ludzi nie chcą implementować i pracować przy takich kobyłach. Ilość miejsc w których może coś się zepsuć może być ogromna pomimo starań projektantów i programistów.

Każdy chce pracować przy małych projektach typu PoC. Z przejrzystymi regułami biznesowymi. Fajnie jest taki model zapewnić. 

SRP - single responsibility principle jako reguła w projektowaniu obiektowym może fajnie oddać idę microservices, tak jak wyżej wspomniane zasady projektowania SOA.


Architektura monolityczna to często dobre rozwiązanie. Stwarzające mniej problemów w integracji i architekturze rozwiązania niż microservices, bo poprostu wołamy metody.

Jak integrować ze sobą microservices  (tak jak SOA) :
    - REST
    - WS*
    - JMS
    - AMPQ
    - HttpInvoker
    - ESB
    - Zookeeper (rejestr)
    - OSGI (wsparcie)

 

Jak do tego się ma Spring Boot ?

Odpowiedź brzmi : - Bardzo dobrze :)

TIP : szybko stwórz projekt

Spring Boot  = start czyli konfiguracja (na przykładzie któregoś z moich projektów)



Spring Boot zapewnia :
  - szybkie prototypowanie ale też production ready

  - automatyczą konfigurację poprzez : 
           - jar
           - class
           - properties
           - etc
      Tu warto się chwilę zatrzymać to jest świetna rzecz.

 
Ok , ale o co chodzi ? - np o to, że jeśli wrzucisz do classpath np h2.jar Spring Boot sam zestawi domyślnie połączenie i pule do bazy. 
Jak dodasz snakeyaml.jar - czytasz properties yaml bez problemu.
TIP : @Conditional - podstawa działania - codzienność od Springa 4 

Dodajesz  PostgreSQL Spring Boot automatycznie zestawia dostawcę persystencji dla bazy postgreSQL.
Chce nadpisać ustawienia lub zmienić parametry - nic prostszego :  

  - dba o odpowiednie wersje jarów
    Chcesz używać JPA ale boisz się, że zapomiesz dodać jakiegoś jara lub dodasz go w złej wersji ? 
   dodajesz tylko deklaracje spring-boot-starter-data-jpa i dostajesz wsparcie dla SpringData oraz ORM.
   
  - uruchamialne jar'y (jako produkt dostajesz dwa jar'y jeden czysty bez zależności drugi z zależnościami)
  java -jar/-war /target/*.jar

 jako produkt gradle build np otrzymuje : 

  ─ libs
│   │   ├── jpakata-0.0.1-SNAPSHOT.jar
│   │   └── jpakata-0.0.1-SNAPSHOT.jar.original



 - standalone application (wbudowany kontener do wyboru tomcat/jetty)
     eliminuje potrzebę instalacji na danym serwerze super feature jeśli chodzi o microservices

 - łatwe uruchamianie aplikacji Web ze standardowego main'a

 - mertyki

    - spring-boot-starter-actuator  = metryki i monitoring
    - spring-boot-starter-remote-shell = mina compoment  - shell access 
    - jolokia
    - coda hel metrics 

 TIP : Remote-shell - Camel mina component

- brak xml

- wsparcie dla Groovy

- możliwość wdrażania w chmurze

Np dla aplikacji Spring MVC oferuje  : 
  • Inclusion of ContentNegotiatingViewResolver and BeanNameViewResolver beans.
  • Support for serving static resources, including support for WebJars (see below).
  • Automatic registration of Converter, GenericConverter, Formatter beans.
  • Support for HttpMessageConverters (see below).
  • Automatic registration of MessageCodeResolver (see below)
  • Static index.html support.
  • Custom Favicon support.

To dużo ....

Jeśli chcesz użyć swoje rozwiązanie zawsze możesz to zrobić Spring Boot pozwala Ci na to :)

Tip : Jeśli masz problemy z ustawianiem aplikacji spójrz na dodatek A dokumentacji Spring Boot (Common Application Properties )


W skład projektu wchodzi :

 Spring Boot - główna biblioteka projektu. Integruje się z innymi częściami Springa

 Spring Boot Autoconfigure - @EnableAutoConfiguration - tworzy cały context Springa
  Zawiera także pakiety do auto-konfiguracji np data, jdbc, logging, security etc
przykład
  W pakietach tych znajdziemy instrukcje budowy kontekstu oraz wstrzeliwania wymaganych zależności i korzystania z własnych lub domyślych ustawień 

Spring Boot Starters -  zbiór zależności dzięki, którym nie martwisz się o pojedyńcze biblioteki

Spring Boot CLI -  wsparcie dla języka Groovy (kompilacja i uruchamianie)

Spring Actuator - production ready features, monitoring

Spring Boot Samples - przykłady użycia


Podsumowanie : 
Spring Boot wydaje się być wprost wymarzonym rozwiązaniem przy implementacji i projektowaniu architektury microservices.

Warto go poznać dla swojej wygody. @Conditional to podstawowa adnotacja - naucz się z niej korzystać. Do zrozumienia i prawidłowej koncepcji microservices polecam przeczytać na sam początek książkę SOA Pattern.
W tej chwili czytam też Oreilly Microservices wczesne wydanie :)     

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 ->