JMS java messaging service

www.proskar.pl

Java Messaging Service

Warsztaty PROSKAR

Plan

1. Wstęp

2. Sposoby komunikacji

• Point-to-point

• Topic

3. Zastosowania JMS

4. Przykładowa aplikacja

www.proskar.pl 2/27

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)

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

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

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

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

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ź

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

JMS

Server aplikacyjny

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.


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


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

Komponenty EJB sterowane komunikatami


– 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

Realne zastosowanie


• 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

• 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


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

Przykładowa aplikacja


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

Zakładka Queue


Interfejs zakładki Queue

• Wiadomość wysłana przed użytkownika kierowana na kolejkę a następnie konsumowana.

• Reprezentuje sposób komunikacji point-to-point


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.


JMSProducer jest klasą producenta JMS. Metoda send wysyła komunikat do obiektu podanego w parametrze.


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.

Zakładka Topic


• Wiadomość jest rozsyłana do wszystkich subskrybentów (odbiorców)

• Korzysta z tematu (topica) udostępnionego na serwerze aplikacyjnym

Interfejs zakładki Topic


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.


Interfejs zakładki Asynchronous

• Asynchroniczne odbieranie wiadomości dzięki klasie MessageListener

• Lista odebranych komunikatów odświeżana jest za pomocą Ajaxa


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.


Dodanie kolejek oraz tematu do pliku wdrożeniowego standalone.xml (WildFly).

Podsumowanie


• 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

JMS java messaging service

Technology