Marcin Łukaszenko Sebastian Urba ski Maciej Zaj c

Marcin Łukaszenko Sebastian Urba ski Maciej Zaj c

1 Wst p W dzisiejszym społecze stwie informacyjnym problem wymiany danych, informacji i komunikatów pomi dzy systemami informatycznymi stanowi bardzo istotn rol. Dla przykładu wyobra my sobie centralny punkt dystrybucji towarów powi zany z sieci punktów sprzeda y. Okre lenie nakładu pracy i czasu, potrzebnych do powiadamiania klientów o zmianach cen, okresowych promocjach, nowych produktach itd. mo e by tylko przybli one, wiadome natomiast jest, e w przypadku nieprzystosowanego do tego celu systemu informatycznego zmuszeni byliby my do opracowania specjalnie do tego celu przeznaczonego protokołu, zapewnienia poprawno ci dostarczenia danych, obsługi dokonywanych wymiany informacji, tworzenia okre lonych ilo ci kopii danych w celu ich dostarczenia do odbiorców. Dodatkowo, w przypadku rozwi zania skalowalnego, czyli przystosowanego do zwi kszania liczby u ytkowników, nale ałoby zaprojektowa i dokona implementacji dedykowanego serwera komunikacyjnego. Problem zdefiniowany w ten sposób doczekał si rozwi zania, jakim jest specyfikacja JMS (Java Message Service) opracowana przez firm Sun Microsystems. Praktyczne wykorzystanie niniejszej specyfikacji zostanie poni ej przedstawione na przykładzie serwera komunikatów SonicMQ firmy Progress. 2 Java Message Service Podstawowym poj ciem zwi zanym ze specyfikacj JMS jest komunikat. Poprzez komunikat rozumiemy pewn informacj o okre lonym formacie. Komunikat taki mo e by przesłany dwukierunkowo mi dzy klientem a serwerem komunikatów. Zaznaczy nale y i w takim systemie nigdy nie dochodzi do bezpo redniej komunikacji pomi dzy systemami klienckimi, dzi ki czemu nie jest konieczne tworzenie systemów homogenicznych. Ka dy komunikat składa si z nagłówka i zawarto ci. W nagłówku znajduj si pola okre laj ce przeznaczenie, typ komunikatu, identyfikator, priorytet i trwało komunikatu. Dodatkowym elementem umieszczanym w nagłówku s własno ci. Własno ci okre lamy par nazwa - warto o okre lonym typie. Zawarto ci komunikatu mo e by tekst, strumienie zawieraj ce warto ci typów prostych i szeregowane obiekty Java. W nagłówku ka dego z komunikatów okre lany jest typ doł czonej zawarto ci. 2

Java Message Service udost pnia dwa modele komunikacji. Sa to model Poin-to-Point i model Publish/Subscribe. W obu modelach dostarczanie komunikatów i ich odbiór odbywa si w sposób asynchroniczny. Model Point-to-Point wykorzystuje kolejki (queues), do których przesyłane s komunikaty. W modelu tym istnieje dokładnie jeden nadawca i jeden odbiorca. Przesyłane komunikaty mog by trwałe, co oznacza, e b d przechowywane przez okre lony czas w serwerze komunikatów. Dzieje si tak tylko wówczas, gdy wcze niej został zarejestrowany odbiorca komunikatów z kolejki i w chwili wysłania komunikatu nie był on przył czony do serwera. Maksymalny czas przechowywania komunikatu wyra amy w milisekundach lub podaj c warto zero sprawiamy, e b dzie przechowywany tak długo, a nie zostanie on odebrany, lub usuni ty w trybie administracyjnym. W modelu Publish/Subscribe komunikaty przesyłane s do okre lonych w złów zwanych tematami (topics). Wyst puje w tym modelu jeden nadawca komunikatów i wielu odbiorców (z punktu widzenia nadawcy odbiorcy s anonimowi, a ich liczba jest nieznana). JMS nie definiuje zasad tworzenia, administracji i usuwania tematu. JMS nie wprowadza te restrykcji okre laj cych, w jaki sposób obiekt tematu jest rejestrowany. Mo e on by zarówno ko cowym elementem w hierarchicznej strukturze tematu, jak i elementem grupuj cym wiele tematów w tej hierarchii (w celu równoczesnej subskrypcji wielu tematów). Organizacja tematów i sposób ich subskrypcji to bardzo wa ne elementy architektury aplikacji wykorzystuj cej model Publish/Subscribe. 2.1 Model komunikatu JMS Kluczowym poj ciem w bibliotece JMS jest komunikat. Komunikat jest sposobem przesyłania informacji pomi dzy aplikacjami klienckimi korzystaj cymi z systemu komunikatów. W skład komunikatu JMS wchodz nast puj ce elementy: nagłówek wszystkie komunikaty posiadaj ten sam zestaw pól składaj cych si na pełn struktur nagłówka. Pola wchodz ce w skład nagłówka s u ywane zarówno przez dostawc jak i klienta do identyfikacji komunikatu oraz wyznaczenia (na podstawie adresu dostawcy i klienta) trasy, jak musi on przeby do miejsca przeznaczenia; wła ciwo ci oprócz standardowych pól wchodz cych w skład struktury nagłówka, mo na zdefiniowa dodatkowe, opcjonalne pola dla ka dego komunikatu. Pola te mog by ro ne dla ró nych komunikatów. Z cechy tej cz sto korzystaj producenci aplikacji implementuj cych standard JMS, w celu łatwego dodania własnej, cz sto dodatkowej, funkcjonalno ci. 3

JMS definiuje tak e pewne pola opcjonalne, równocze nie producenci systemu komunikatów definiuj własne pola. Pola opcjonalne zdefiniowane przez JMS to: JMSXUserId zawiera identyfikator u ytkownika wysyłaj cego wiadomo ; JMSXAppID zawiera identyfikator transakcji, w ramach której została wysłana ta wiadomo ; JMSXConsumerTXID zawiera identyfikator transakcji, w ramach której została odebrana ta wiadomo ; JMSXRcvTimeStamp zawiera informacj o czasie dostarczenia wiadomo ci do konsumenta; JMSXState zawiera informacj o statusie wiadomo ci: 1 wiadomo czeka na wysłanie, 2 gotowa do wysłania, 3 upłyn ł termin wa no ci, 4 wiadomo zatrzymana; ciało zawiera tre wiadomo ci. Standard JMS definiuje kilka typów ciała wiadomo ci, które obejmuj wi kszo obecnie u ywanych typów: komunikat tekstowy (TextMessage), komunikat typu obiekt (ObjectMessage), strumie bajtów (BytesMessage), strumie zmiennych Javy o typach podstawowych (StreamMessage), komunikat zawieraj cy pary typu nazwa warto (MapMessage). W systemach komunikatów u ywane s głównie dwa główne typy wiadomo ci TextMessage i ObjectMessage. TextMessage słu y do wysyłania wiadomo ci tekstowych, natomiast ObjectMessage słu y do przesyłania całych serializowalnych obiektów Javy do innego klienta korzystaj cego z systemu komunikatów. Pełny nagłówek komunikatu przesyłany jest do wszystkich klientów zainteresowanych odbiorem komunikatu. Pola wchodz ce w skład struktury nagłówka komunikatu to: pole JMSDestination - zawiera docelowy adres wysyłanego komunikatu. pole JMSMessageID - przechowuje unikaln warto u ywan do identyfikacji ka dego komunikatu wysłanego przez dostawc. Warto przechowywana przez pole JMSMessageID jest ła cuchem znaków i musi si ona zaczyna prefiksem ID. Wymagana jest unikalno tego pola w obr bie ka dego dostawcy. 4

pole JMSTimestamp - zawiera informacj o czasie okre laj cym moment zaakceptowania wiadomo ci przez system komunikatów. Nie jest to czas, w którym wiadomo została wysłana, poniewa zdarzenie to mo e wyst pi pó niej ni faktyczny czas przyj cia wiadomo ci przez system kolejkowy. Zazwyczaj producenci systemów kolejkowych zalecaj wył czenie w systemie ustawiania tego pola. pole JMSCorrelationID - mo e by u ywane przez klienta w celu poł czenia jednego komunikatu z innym. Zazwyczaj pole to u ywane jest do poł czenia odebranego komunikatu z wysyłanym komunikatem odpowiedzi na odebrany komunikat. Poniewa pole to wskazuje na pole JMSMessageID innego komunikatu, obowi zuj go takie same restrykcje, co pole JMSMessageID. pole JMSReplyTo -zawiera adres, na który powinna zosta wysłana odpowied na komunikat z wypełnionym tym polem komunikaty z wypełnionym polem JMSReplyTo oczekuj odpowiedzi od klienta, który taki komunikat odebrał, ale to wła nie klient decyduje o wysłaniu (lub nie) odpowiedzi. pole JMSRedelivered - je li klient otrzymuje komunikat z wypełnionym polem JMSRedelivered, wiadczy to o tym, e najprawdopodobniej komunikat ten został ju dostarczony do klienta wcze niej, lecz nie zostało wysłane przez klienta potwierdzenie otrzymania tego komunikatu. pole JMSType - przechowuje informacje o typie wysłanego komunikatu. pole JMSExpiration - okre la czas wa no ci wiadomo ci kiedy komunikat jest wysyłany, jego czas wa no ci okre lany jest na podstawie warto ci time-to-live wyszczególnionej w wywołaniu metody odpowiedzialnej za wysłanie wiadomo ci oraz aktualnego czasu. Podczas wywołania metody wysyłaj cej komunikat, polu JMSExpiration przypisana zostaje wyliczona w ten sposób warto, i nie ulega ona zmianie w momencie odebrania komunikatu przez innego klienta JMS. Je li warto parametru time-to-live metody odpowiedzialnej za wysłanie komunikatu, została ustalona na zero, oznacza to, e wa no komunikatu nie wygasa. pole JMSPriority - okre la ono priorytet wiadomo ci. JMS definiuje dziesi ciopoziomow skal warto ci przyjmowanych przez pole JMSPriority: od 0 do 9, przy czym priorytet o numerze 0 oznacza priorytet najni szy, o numerze 9 najwy szy. Klienci powinni traktowa priorytety 0-4 jako gradacj normalnego priorytetu, a 5-9 jako gradacj wysokiego. JMS nie wymaga od producentów systemów komunikatów cisłego przestrzegania i implementacji porz dku priorytetów komunikatu, jednak e zaleca, by 5

komunikaty posiadaj ce priorytet rz du 5-9 zostały wysłane przed komunikatami o normalnym priorytecie. pole JMSDeliveryMode - przechowuje ono informacje o trwało ci komunikatu. Mo e przyj jedn z dwóch warto ci: javax.jms.deliverymode.persistent komunikat trwały javax.jms.deliverymode.non_persistent komunikat nietrwały 2.2 Wła ciwo ci komunikatu Oprócz pól wynikaj cych ze struktury nagłówka, komunikat posiada równie mo liwo przechowania dodatkowych, zdefiniowanych przez klienta JMS, pól. Pole takie rozbija si na par podpól: nazwa warto. Podpole warto mo e by typu boolean, byte, short, int, long, float, double lub ich odpowiedników obiektowych (Boolean, Byte, Short, Integer, Float, Double) lub String, i przyjmowa warto ci odpowiednie dla ka dego z wymienionego typu. 2.3 Trwało komunikatu JMS definiuje dwa rodzaje wiadomo ci: nietrwałe (non persistent) i trwałe (persistent). Ka dy komunikat przed wysłaniem ma ustawiane pole JMSDeliveryMode - przyjmuje ono jedn z dwóch warto ci: javax.jms.deliverymode.persistent dla okre lenia komunikatu trwałego lub javax.jms.deliverymode.non_persistent dla okre lenia komunikatu nietrwałego. JMS zapewnia dostarczenie komunikatów oznaczonych jako trwałe wszystkim klientom zainteresowanym ich odbiorem i b d cych zarejestrowanymi jako trwali odbiorcy (durable subscriber). Trwałe komunikaty zapisywane s w wewn trznej bazie danych serwera JMS w momencie otrzymania przez serwer trwałego komunikatu, a usuwane gdy wszyscy zarejestrowani trwali odbiorcy zgłosz potwierdzenie otrzymania tego komunikatu: Komunikaty te s dostarczane odbiorcom nawet w przypadku awarii serwera czy odbiorcy. 2.4 Model Point-to-Point Model Point-to-Point wykorzystuje kolejki, do których przesyłane s komunikaty. W modelu tym istnieje dokładnie jeden nadawca i dokładnie jeden odbiorca. Przesyłane komunikaty mog by trwałe, co oznacza, e b d przechowywane przez pewien okre lony czas w serwerze komunikatów. Dzieje si tak tylko wówczas, gdy wcze niej został zarejestrowany odbiorca komunikatów z kolejki i w chwili wysłania komunikatu nie był on 6

przył czony do serwera. Maksymalny czas przechowywania komunikatu nie jest okre lony przez JMS. Wyra amy go w milisekundach lub podaj c warto zero sprawiamy, e komunikat b dzie przechowywany tak długo, a nie zostanie odebrany lub usuni ty w trybie administracyjnym. Do utworzenia obiektu QueueConnection, który jest aktywnym poł czeniem do serwera, wykorzystywana jest metoda QueueConnectionFactory. Klient u ywa obiektu QueueConnection do utworzenia jednej lub wielu sesji QueueSession wykorzystywanych w celu wysyłania i odbierania komunikatów. Sesja QueueSession dostarcza metod umo liwiaj cych tworzenie obiektów typu QueueSender i QueueReceiver. Obiekt QueueSender słu y do wysyłania komunikatów do kolejki, natomiast QueueReceiver do odbierania komunikatów opublikowanych we wskazanej kolejce. Mo liwe jest równoczesne utworzenie dwóch obiektów QueueReceiver dla tej samej kolejki. W nagłówku komunikatu mog by zawarte informacje umo liwiaj ce odbiór wyselekcjonowanej grupy komunikatów. 2.5 Model Publish/Subscribe W modelu Publish/Subscribe komunikaty przesyłane s do okre lonych w złów zwanych tematami (topic). W modelu tym wyst puje jeden nadawca komunikatów i wielu odbiorców, którzy z punktu widzenia nadawcy s anonimowi, a ich liczba jest nieznana. JMS nie definiuje zasad tworzenia, administracji i usuwania tematu. Klient u ywa metody TopicConnectionFactory do utworzenia poł czenia TopicConnection z serwerem komunikatów. TopicConnection jest aktywnym poł czeniem, którego klient u ywa do tworzenia jednej lub wielu sesji TopicSessions wykorzystywanych w celu wysyłania i odbierania komunikatów. Sesja TopicSession dostarcza metod umo liwiaj cych tworzenie obiektów typu TopicPublisher i TopicSubscriber. Pierwszy z nich umo liwia wysyłanie komunikatów do tematu, natomiast drugi słu y klientowi do odbierania komunikatów opublikowanych we wskazanym temacie. Obiekt TopicSubscriber domy lnie nie umo liwia publikowania trwałych komunikatów. Słu y on tylko do odbioru komunikatów opublikowanych w chwili jego poł czenia z serwerem. Aby odbiera trwałe komunikaty nale y wykorzysta obiekt DurableTopicSubscriber. Odbiór komunikatów w obu modelach komunikacji wykorzystuje delegacyjny model obsługi zdarze. Obiekt oddelegowany do obsługi zdarze zwi zanych z nadchodz cymi komunikatami musi implementowa interfejs MessageListener i pokrywa jego metod onmessage. Argumentem metody onmessage jest obiekt klasy Message, który reprezentuje odbierany komunikat. 7

3 SonicMQ Produkt SonicMQ jest serwerem komunikatów firmy Progress b d cym kompletn implementacj standardu Java Message Service. Został on w cało ci napisany w Javie i wspiera platform JVM. Jest to przykład zastosowania standardu JMS w rzeczywistej aplikacji przeznaczonej do pełnienia funkcji brokera komunikatów. Oprócz implementacji standardu JMS, SonicMQ oddaje równie do dyspozycji twórców aplikacji sieciowych dwie nowe funkcje, a mianowicie hierarchiczn przestrze nazw i mo liwo tworzenia aplikacji klienckich wykorzystuj cych kontrolki ActiveX. Główne cechy SonicMQ to przede wszystkim: Wydajno - osługa multipleksowanego Brokera pozwala przeł cza si mi dzy serwerami komunikatów w celu zapewnienia ci głego poł czenia. Funkcja ta udost pnia klientom mechanizm łatwej wymiany informacji w sieciach rozproszonych i poprawia ogóln wydajno. Asynchroniczne odpowiedzi umo liwiaj klientom oczekuj cym na odpowied kontynuacj zainicjowanych procesów do czasu otrzymania odpowiedzi; inaczej ni w przypadku komunikacji dwukierunkowej. Niezawodno - mechanizm gwarantowanego dostarczania komunikatów zapewnia wszystkim u ytkownikom ł cznie z u ytkownikami nie pracuj cymi w trybie podł czony i u ytkownikami mobilnymi odbiór wszystkich komunikatów. SonicMQ zawiera kompletne zabezpieczenia, obsługuje identyfikacj, autoryzacj, kontrol dost pu, cyfrowe certyfikaty i szyfrowanie kluczami 40- i 128-bitowymi. Komunikaty dostarczone do serwera s przechowywane w doł czonej bazie danych (lub poprzez JDBC w innej wskazanej bazie), dzi ki czemu zapewnione jest wi ksze bezpiecze stwo w przypadku awarii systemu. Wsparcie transakcji umo liwia grupowanie komunikatów w jednostki logiczne i wykonywanie na nich operacji commit i rollback jak na pojedynczym komunikacie. Elastyczno - model komunikatów typu Point-to-Point obsługuje mechanizm dostarczania komunikatów do wskazanych kolejek. Dzi ki temu mo e je odebra tylko jeden klient, nawet w sytuacji, gdy wielu klientów monitoruje kolejk. Model komunikatów typu Publish-and-Subscribe umo liwia nadawcy wysyłanie komunikatów do tematów, które subskrybuje wielu klientów, a temat rozsyła do klientów kopie komunikatu. Komunikaty w formacie XML s własnym rozszerzeniem serwera SonicMQ w stosunku do standardowych typów technologii JMS. 8

Łatwo u ycia - zdalna administracja czyni łatwym monitorowanie, zarz dzanie i konserwacj brokerów komunikatów, zarówno w systemach lokalnych jak i zdalnych. Wszystkie te czynno ci wykonywane s z jednego miejsca przy u yciu narz dzi graficznych lub narz dzi uruchamianych na konsoli tekstowej. Przezroczysto lokalizacji zapewnia mechanizm adresowania w oparciu o nagłówki. Zarówno klienci, jak i serwery mog zmienia lokalizacj bez konieczno ci dokonywania zmian w infrastrukturze komunikatów. Broker SonicMQ rozsyła komunikaty na podstawie nagłówka lub zawarto ci, a nie na podstawie adresu IP, jak to ma miejsce w tradycyjnych systemach komunikatów. Hierarchiczne adresowanie obsługuje hierarchi tematów i umo liwia klientowi inteligentne subskrybowanie wskazanych tematów wraz z podtematami. Klient nie musi wskazywa jawnie nazw tematów, lecz mo e subskrybowa grupy tematów bez konieczno ci znania ich nazw i liczno ci. 4 Przykład aplikacji wykorzystuj cej JMS i SonicMQ W celu przybli enia rzeczywistego zastosowania standardu JMS i implementuj cego go brokera komunikatów SonicMQ wyobra my sobie system obsługuj cy dystrybucj towarów np. sprzeda telefonów komórkowych. W skład systemu wchodzi centralny punkt dystrybucji CPD oraz punkty sprzeda y PS. CPD oferuje pełen asortyment marek i modeli telefonów komórkowych i zajmuje si ich dystrybucj do punktów sprzeda y, które sprzedaj towar klientom. Oferta w Centrali zmienia si cz sto, a co wi cej zmieniaj si równie ceny oferowanych aparatów. Wymaga to ci głej dystrybucji informacji na te tematy. Idealnym rozwi zaniem, które mo na wykorzysta do tego celu jest dystrybucja komunikatów z takimi informacjami poprzez broker komunikatów implementuj cy JMS i wykorzystanie komunikacyjnego modelu Publish/Subscribe. Dzi ki temu CPD b dzie generowa komunikaty skierowane do odpowiedniego tematu (topic) natomiast wszystkie punkty sprzeda y b d zarejestrowanymi odbiorcami danego tematu, dzi ki czemu ka dy komunikat b dzie na bie co udost pniany aktywnym w danym momencie adresatom. Co wi cej komunikat b d c trwałym pozostanie w kolejce do czasu odebrania go przez wszystkie punkty sprzeda y zarejestrowane jako odbiorcy danego tematu. W opisywanym modelu dystrybucji telefonów komórkowych przydatn funkcjonalno ci jest zaimplementowana mo liwo zgłaszania przez punkty sprzeda y zamówie na okre lone ilo ci wybranych telefonów i obsługa takiego zamówienia przez cały jego cykl ycia. Do tego 9

celu wykorzystuje si model komunikacyjny Point-to-Point. Rozwi zanie to pozwala wysyłanie przez PS zamówienia w postaci komunikatu do odpowiedniej kolejki, z której odbiór mo e zrealizowa tylko jeden adresat CPD. Model ten wykorzystany jest dwukierunkowo, tzn. CPD komunikuje si z danym PS poprzez t sam kolejk, zaznaczaj c dokładnie adresata takiego komunikatu, czyli wybrany punkt sprzeda y. Dzi ki temu w punkcie sprzeda y na bie co wiadomo, jaki jest status danego zamówienia czy jest ono zaakceptowane, realizowane, czy mo e odrzucone. Dodatkowo po odebraniu przesyłki zawieraj cej zamówiony towar, PS zobowi zany jest wysła kolejny komunikat informuj cy CPD o odebraniu przesyłki. W ten sposób obsługiwany jest cały cykl ycia zamówienia od jego zło enia i obsług, a do zrealizowania i przeniesienia do archiwum. Przedstawione powy ej rozwi zanie jest bardzo ciekawym przykładem wykorzystania standardu JMS i implementuj cego go produktu SonicMQ. W celu przybli enia szczegółów rozwi zania sporz dzono poni szy rysunek przedstawiaj cy model komunikacji pomi dzy CPD a wieloma punktami sprzeda y. Centralny Punkt Dystybucyjny CPD Nasłuch komunikatów Broker Komunikatów SonicMQ Punkt Sprzeda y PS 1 Baza Danych Punkt Sprzeda y PS n Warto zauwa y, e zastosowano element po rednicz cy w wymianie danych pomi dzy systemem zewn trznym (brokerem komunikatów z sieci poł czonych do niego punktów sprzeda y), a systemem wewn trznym (baz danych i aplikacj dedykowan do obsługi CPD). Jest to moduł oczekuj cy na nadej cie komunikatów od brokera, informuj cy wła ciw aplikacj CPD o takim fakcie oraz zapisuj cym do bazy danych odebrane komunikaty. Moduł ten słu y aplikacji CPD do wysyłania komunikatów do brokera, który przejmuje ci ar dostarczenia informacji dalej do odpowiednich punktów sprzeda y. 10