Komunikacja asynchroniczna w Javie pozwala na tworzenie systemów luźno powiązanych współpracujących z sobą w sieci o niskiej niezawodności, takiej jak Internet.

Oprogramowanie warstwy pośredniej (middleware), pozwalające na asynchroniczną wymianę komunikatów za pomocą kolejek (message queuing), nabiera coraz większego znaczenia w rozwiązaniach internetowych. Do niedawna ta kategoria oprogramowania była prawie wyłączną domeną programu MQSeries firmy IBM, który ma ok. 75-proc. udział w rynku. Jednakże Sun z oprogramowaniem Java Message Service (JMS) staje się coraz poważniejszym konkurentem IBM.

Dostęp do komunikatów

JMS to zestaw funkcji programistycznych API dostępu do różnych systemów obsługi komunikatów. Jest w pewnym sensie odpowiednikiem JDBC, zestawu funkcji API dostępu do relacyjnych baz danych. JMS pozwala na przesyłanie komunikatów między różnymi aplikacjami poprzez serwer obsługi komunikatów. Klient JMS wysyła komunikat do kanału wirtualnego (kolejki lub tematu), który jest prenumerowany przez innego klienta. Komunikat może być wysłany do jednego klienta lub wielu.

Pierwsza znana realizacja serwera obsługi komunikatów Java to SonicMQ firmy Progress Software. Istnieją również ograniczone funkcjonalnie implementacje JMS wbudowane np. w serwer aplikacyjny WebLogic (BEA Systems) i serwer XML Excelon (firmy Excelon). Zapewne JMS w krótkim czasie nie pokona MQSeries, ale elastyczność rozwiązania Suna, wynikająca z pracy na dowolnym systemie operacyjnym, jest jego dużą zaletą. Podobnie zresztą jak cena - SonicMQ kosztuje 3 tys. USD (jeden procesor), podczas gdy inwestycja w MQSeries wiąże się z kosztem co najmniej 100 tys. USD.

JMS został zdefiniowany przez Suna w celu udostępnienia programistom sposobu wysyłania komunikatów między aplikac-jami Java. Obecnie komunikacja między komponentami Enterprise Java Beans (EJB) na różnych systemach komputerowych może być jedynie synchroniczna po otwarciu dwukierunkowego łącza w sieci TCP/IP. Dwie istniejące wersje EJB (beany sesji i beany encji) nie odbierają komunikatów asynchronicznych. Aby z nich skorzystać, muszą być wywołane bezpośrednio przez aplikację.

W propozycji nowej specyfikacji EJB 2.0, włączonej do specyfikacji J2EE 1.3, zintegrowano JMS, tworząc nowy rodzaj beanu asynchronicznego MessageDrivenBean, którego usługi może wywoływać kontener beanów po otrzymaniu komunikatu z dowolnego serwera komunikatów asynchronicznych (niekoniecznie zgodnego z JMS). MessageDrivenBean znacznie uprości przetwarzanie komunikatów JMS. Specyfikacja JMS nie określa, za pomocą jakiego protokołu są przesyłane komunikaty między serwerem JMS a klientami. Jest to o tyle ważne, że w systemach rozproszonych istnieje również potrzeba wzajemnego komunikowania się serwerów JMS. SonicMQ Progressa posługuje się HTTP lub TCP/IP. Programy IBM MQSeries natomiast korzystają z firmowego protokołu, podobnie jak inne implementacje systemów obsługi komunikatów.

JMS w praktyce

Z serwera komunikatów SonicMQ korzysta jedna z największych sieci handlu w Internecie Commerce One. Oprogramowania Progressa używa ona do opracowania aplikacji wymiany dokumentów tekstowych, a nawet plików multimedialnych. Wbudowany w SonicMQ protokół komunikacji za pośrednictwem bezpiecznych gniazdek SSL (Secure Socket Layer) pozwala na ochronę danych w trakcie przesyłania.

Analitycy największą szansę dla JMS widzą w stosowaniu go do przesyłania komunikatów języka XML, pretendującego do miana standardu wymiany danych między różnymi aplikacjami.