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

Brak komentarzy:

Prześlij komentarz