JMS java messaging service

1. www.proskar.pl
Java Messaging Service
Warsztaty PROSKAR

2. Plan
1. Wstęp
2. Sposoby komunikacji
• Point-to-point
• Topic
3. Zastosowania JMS
4. Przykładowa aplikacja
www.proskar.pl 2/27

3. Wstęp
• Definicja
– Zestaw interfejsów i modeli asynchronicznego przesyłania
komunikatów
– Umożliwia korzystanie z systemów kolejkowania w
aplikacjach używających technologii wchodzących w skład
specyfikacji JEE
www.proskar.pl 3/27
Schemat działania JMS komunikacji point-to-point
(Źródło www.access.redhat.com)

4. Sposoby komunikacji
www.proskar.pl 4/27
Komunikaty przesyłane są pomiędzy producentem i
konsumentem za pomocą JMS udostępnionego przez serwer
aplikacyjny.
Sposoby komunikacji:
• point-to-point
• topic

5. Point-to-point
www.proskar.pl 5/27
Komunikacja pomiędzy dwoma klientami, gdzie producent jest
nadawcą, a konsument odbiorcą. Komunikat skonsumowany
przed odbiorcę nie jest dłużej przetrzymywany w kolejce.
Producent Kolejka Konsument

6. Topic
www.proskar.pl 6/27
Producent wysyła komunikat na temat (topic), a JMS rozsyła je
do subskrybentów. JMS umożliwia szybkie rozsyłanie
komunikatu do wielu odbiorców.
Producent Topic
Subskrybent
Subskrybent
Subskrybent

7. Zastosowania JMS
www.proskar.pl 7/27
• Komunikacja pomiędzy modułami wewnątrz serwera
aplikacyjnego
• Komunikacja między modułami na rożnych serwerach
aplikacyjnych
• EJB – Komponenty sterowane komunikatami

8. Komunikacja pomiędzy modułami wewnątrz
serwera aplikacyjnego
www.proskar.pl 8/27
• Moduły znajdują się na serwerze aplikacyjnym
implementującym standard JMS
• Komunikacja pomiędzy modułami
– Moduł I wysyła komunikat na kolejkę
– Kolejka przechowuje komunikat do skonsumowania przez
odbiorcę
– Moduł II konsumuje komunikat i go przetwarza
– Moduł II wysyła odpowiedź

9. www.proskar.pl 9/27
Przykładowy schemat aplikacji w której dwa
moduły komunikują się ze sobą za pomocą JMS.
Moduł I Moduł IIJMS
Server aplikacyjny

10. Komunikacja pomiędzy modułami na
różnych serwerach aplikacyjnych
www.proskar.pl 10/27
– Moduły znajdują się na różnych serwerach aplikacyjnych
implementujących standard JMS.
– Oba serwery aplikacyjne maja skonfigurowaną
funkcjonalność JMS Bridge odpowiedzialną za
komunikowanie się z innymi serwerami.
– Komunikacja odbywa się podobnie jak w przypadku
modułów znajdujących się na tym samym serwerze
aplikacyjnym. Różnicą jest to, że komunikat kierowany jest
poza serwer aplikacyjny.

11. www.proskar.pl 11/27
Przykładowy schemat architektury systemu, którego moduły
znajdują się na dwóch serwerach aplikacyjnych, a za
komunikację między nimi odpowiada JMS.
Moduł ModułJMS
Serwer aplikacyjny Serwer aplikacyjny
JMS

12. www.proskar.pl 12/27
Zalety takiego rozwiązania:
– Moduły nie muszą znać swojej struktury, do kolejki
wrzucane są gotowe dane do obioru
– W przypadku zmian wprowadzonych na jednym z
modułów nie ma potrzeby wprowadzania zmian na drugim
(jak ma to miejsce np. przy użyciu WebService).
– Łatwa implementacja kodu odpowiadającego za
asynchroniczną komunikację.

13. Komponenty EJB sterowane komunikatami
www.proskar.pl 13/27
– Klasy których metody mogą być wywoływane przez
wysyłane do nich komunikaty.
– Z chwilą pojawienia się komunikatu w kolejce, którą
obsługuje dany komponent, wywoływana jest
odpowiednia metoda komponentu.
– Oferują implementację ułatwiającą budowanie aplikacji z
użyciem JMS
• Potwierdzanie odbioru komunikatu
• Przechowywanie danych o nadawcy w komunikacie

14. Realne zastosowanie
www.proskar.pl 14/27
• Kiedy warto używać JMS?
– Odpowiedź z integrowanego modułu zajmuje zbyt dużo
czasu
– Z jednego zasobu korzysta wielu klientów
– Wymagana jest asynchroniczna komunikacja np.
wyświetlanie szczątkowych wyników operacji

15. • Przykładowy problem
– Aplikacja odpowiedzialna za wyświetlanie historii notowań
giełdowych.
– Korzysta z modułu odpowiedzialnego za generowanie
historii według podanego filtru.
– W zależności od filtrów wybranych przez użytkownika,
generowanie historii może trwać długo.
15/27

16. www.proskar.pl 16/27
• Rozwiązanie:
– Klient ustawia filtr według którego ma zostać
wygenerowana historia
– Aplikacja wrzuca na kolejkę in_getHistory obiekt
zawierający informacje o zapytaniu klienta
– Moduł odbiera obiekt z kolejki i przetwarza dane.
– W czasie przetwarzania danych na kolejkę wyjściową
out_getHistory wrzucane są częściowe wyniki operacji.
– Aplikacja odbiera części przetworzonych danych i drukuje
je na ekranie.

17. Przykładowa aplikacja
www.proskar.pl 17/27
Przykładowa aplikacja ukazuje różne sposoby rozsyłania
komunikatów JMS. GUI aplikacji został napisany w technologii
JSF i składa się z trzech zakładek:
– Queue
– Topic
– Asynchronous

18. Zakładka Queue
www.proskar.pl 18/27
Interfejs zakładki Queue
• Wiadomość wysłana przed użytkownika kierowana na kolejkę
a następnie konsumowana.
• Reprezentuje sposób komunikacji point-to-point

19. www.proskar.pl 19/27
Konsument pobiera komunikat z kolejki i dodaje ją do listy
odebranych komunikatów. Wiadomość jest usuwana z kolejki.
Referencje do obiektu kolejki oraz fabryki połączenia z JMS
można pobrać z kontekstu JNDI ENC.

20. www.proskar.pl 20/27
JMSProducer jest klasą producenta JMS. Metoda send wysyła
komunikat do obiektu podanego w parametrze.

21. www.proskar.pl 21/27
Klasa konsumenta różni się od klasy producenta tylko metodą
odbierającą:
Metoda klasy JMSConsumer receiveBodyNoWait jest
odpowiedzialna za pobieranie komunikatu, w odróżnieniu od
metody receive nie musi zwracać komunikatu jeżeli kolejka
jest pusta.

22. Zakładka Topic
www.proskar.pl 22/27
• Wiadomość jest rozsyłana do wszystkich subskrybentów
(odbiorców)
• Korzysta z tematu (topica) udostępnionego na serwerze
aplikacyjnym
Interfejs zakładki Topic

23. www.proskar.pl 23/27
Podobnie jak w poprzedniej zakładce należy dokonać
wstrzyknięcia obiektów fabryki połączenia z systemem JMS
oraz tematu (Topic).
Wysyłanie komunikatów odbywa się za pomocą metody
obiektu JMSProducer.

24. www.proskar.pl 24/27
Interfejs zakładki Asynchronous
• Asynchroniczne odbieranie wiadomości dzięki klasie
MessageListener
• Lista odebranych komunikatów odświeżana jest za pomocą
Ajaxa

25. www.proskar.pl 25/27
Przykładowa implementacja klasy nasłuchującej
Odbieranie komunikatów za pomocą klasy MessageListener
będącą klasą nasłuchującą. Metoda onMessage wywoływana
jest gdy komunikat pojawia się na kolejce.

26. www.proskar.pl 26/27
Dodanie kolejek oraz tematu do pliku wdrożeniowego
standalone.xml (WildFly).

27. Podsumowanie
www.proskar.pl 27/27
• Szybki sposób na komunikację pomiędzy modułami aplikacji
• Odporny na modyfikacje
• Umożliwia asynchroniczną wymianę informacji
• Pozwala na komunikację z wieloma klientami jednocześnie
• Zbyt uzależniony od implementacji JMS serwera aplikacyjnego
na którym się znajduje
• Konieczność tworzenia dużej ilości kolejek przy większych
systemach