Wiadomości z Dżakarty - Jakarta Messaging

Jakarta Messaging API (dawniej Java Message Service lub JMS API) jest Java interfejs programowania aplikacji (API) dla wiadomości-Oriented Middleware . Zapewnia generyczne modele przesyłania wiadomości, które są w stanie poradzić sobie z problemem producent-konsument , które można wykorzystać do ułatwienia wysyłania i odbierania wiadomości między systemami oprogramowania . Jakarta Messaging jest częścią Jakarta EE i została pierwotnie zdefiniowana przez specyfikację opracowaną w Sun Microsystems przed kierowaniem przez Java Community Process .

Ogólna idea przesyłania wiadomości

Zobacz też: Oprogramowanie pośredniczące zorientowane na wiadomości i przekazywanie wiadomości

Komunikaty to forma luźno powiązanej komunikacji rozproszonej, gdzie w tym kontekście pojęcie „komunikacja” może być rozumiane jako wymiana komunikatów między komponentami oprogramowania. Technologie zorientowane na komunikaty próbują rozluźnić ściśle powiązaną komunikację (taką jak gniazda sieciowe TCP , CORBA lub RMI ) poprzez wprowadzenie komponentu pośredniczącego. Takie podejście umożliwia pośrednią komunikację między komponentami oprogramowania. Korzyści z tego wynikają z tego, że nadawcy wiadomości nie muszą posiadać dokładnej wiedzy o swoich odbiorcach.

Korzyści płynące z przesyłania wiadomości obejmują możliwość integracji heterogenicznych platform, zmniejszenie wąskich gardeł systemu, zwiększenie skalowalności i szybsze reagowanie na zmiany.

Historia wersji

  • JMS 1.0
  • JMS 1.0.1 (5 października 1998)
  • JMS 1.0.1a ( 30.10.1998 )
  • JMS 1.0.2 (17 grudnia 1999)
  • JMS 1.0.2a (23 grudnia 1999)
  • JMS 1.0.2b (27 sierpnia 2001)
  • JMS 1.1 (12 kwietnia 2002)
  • JMS 2.0 (21 maja 2013)
  • JMS 2.0a ( 16.03.2015 )

JMS 2.0 jest obecnie utrzymywany w ramach Java Community Process jako JSR 343.

JMS 3.0 jest na wczesnym etapie rozwoju w ramach Jakarta EE.

Elementy

Poniżej znajdują się elementy JMS:

dostawca JMS
Implementacja interfejsu JMS dla oprogramowania pośredniczącego zorientowanego na komunikaty (MOM). Dostawcy są implementowani jako implementacja Java JMS lub adapter do MOM innego niż Java.
Klient JMS
Aplikacja lub proces, który generuje i/lub odbiera komunikaty.
Producent/wydawca JMS
Klient JMS, który tworzy i wysyła komunikaty.
Konsument/subskrybent JMS
Klient JMS odbierający komunikaty.
Wiadomość JMS
Obiekt zawierający dane przesyłane między klientami JMS.
Kolejka JMS
Obszar pomostowy zawierający wiadomości, które zostały wysłane i oczekują na przeczytanie (tylko przez jednego konsumenta). Jak sugeruje kolejka nazw, wiadomości są dostarczane w kolejności wysłanej. Kolejka JMS gwarantuje, że każdy komunikat jest przetwarzany tylko raz.
Temat JMS
Mechanizm dystrybucji do publikowania wiadomości, które są dostarczane do wielu subskrybentów.

Modele

Interfejs API JMS obsługuje dwa różne modele:

  • Punkt-punkt
  • Publikuj i subskrybuj

Model punkt-punkt

W ramach systemu przesyłania wiadomości typu punkt z punktem wiadomości są kierowane do poszczególnych odbiorców, którzy utrzymują kolejki wiadomości przychodzących. Ten typ wiadomości jest oparty na koncepcji kolejek wiadomości , nadawców i odbiorców. Każda wiadomość jest adresowana do określonej kolejki, a klienci odbierający wyodrębniają wiadomości z kolejek ustanowionych do przechowywania ich wiadomości. Podczas gdy dowolna liczba producentów może wysyłać komunikaty do kolejki, każdy komunikat ma gwarancję dostarczenia i wykorzystania przez jednego konsumenta. Kolejki przechowują wszystkie wysłane do nich wiadomości, dopóki wiadomości nie zostaną wykorzystane lub do momentu wygaśnięcia wiadomości. Jeśli żaden konsument nie jest zarejestrowany do korzystania z komunikatów, kolejka wstrzymuje je, dopóki konsument nie zarejestruje się, aby je wykorzystać.

Model publikowania i subskrybowania

Model publikuj i subskrybuj obsługuje publikowanie wiadomości w określonym „temacie” wiadomości. Abonenci mogą zgłaszać zainteresowanie otrzymywaniem wiadomości publikowanych na określony temat wiadomości. W tym modelu ani wydawca, ani subskrybent nie wiedzą o sobie nawzajem. Dobrą analogią do tego jest anonimowa tablica ogłoszeń.

  • Wiadomość otrzyma zero lub więcej konsumentów.
  • Istnieje zależność czasowa między wydawcami a subskrybentami. Wydawca musi utworzyć temat wiadomości do subskrybowania przez klientów. Abonent musi być stale aktywny, aby otrzymywać wiadomości, chyba że ustanowił trwałą subskrypcję. W takim przypadku wiadomości publikowane, gdy abonent nie jest połączony, będą rozpowszechniane przy każdym ponownym połączeniu.

JMS umożliwia oddzielenie aplikacji od warstwy transportowej dostarczania danych. Te same klasy Java mogą być używane do komunikowania się z różnymi dostawcami JMS przy użyciu informacji Java Naming and Directory Interface (JNDI) dla żądanego dostawcy. Klasy najpierw używają fabryki połączeń do łączenia się z kolejką lub tematem, a następnie używają wypełniania i wysyłania lub publikowania komunikatów. Po stronie odbierającej klienci odbierają lub subskrybują wiadomości.

Schemat URI

RFC 6167 definiuje jms: schemat URI dla usługi Java Message Service.

Implementacje dostawcy Provider

Aby korzystać z JMS, trzeba mieć dostawcę JMS, który może zarządzać sesjami, kolejkami i tematami. Począwszy od wersji 1.4 Java EE, dostawca JMS musi być zawarty we wszystkich serwerach aplikacji Java EE. Można to zaimplementować za pomocą zarządzania przepływem komunikatów architektury Java EE Connector Architecture , która została po raz pierwszy udostępniona w tej wersji.

Poniżej znajduje się lista popularnych dostawców JMS:

Zobacz też

Bibliografia

Dalsza lektura

  • Richards, Mark; Richarda Monsona-Haefela; David A. Chappell (2009). Usługa wiadomości Java, wydanie drugie . O'Reilly. Numer ISBN 978-0-596-52204-9.

Linki zewnętrzne