EJB3 - MDB

Po co stosować komunikację przy pomocy komunikatów

żeby klient nie blokował się w oczekiwaniu na odpowiedź
żeby klient i serwer nie musiały być dostępne w tym samym czasie
jeżeli jest kilku klientów lub kilka serwerów

Realizacja

Powyższe zalety uzyskujemy dzięki wprowadzeniu serwera pośredniczącego, tzw. Message-oriented middleware (MOM). Jak to zwykle bywa pośrednik rozwiązuje kilka problemów, ale wprowadza narzut na efektywność. Użycie napisanego przez ekspertów MOM umożliwia skorzystanie z wielu przydatnych funkcji (np. gwarantowane dostarczanie wiadomości lub równoważenie obciążenia) i skupić się na zadaniu które próbujemy rozwiązać.

Java Message Service (JMS) to API standaryzujące sposób dostępu do usług MOM w programach napisanych w Javie. Pomysł jest analogiczny do JNDI i JDBC.

Komunikaty są wysyłane przez producetów do celu (destination), który je przesyła do konsumentów. Pośredniczenie może odbywać się na dwa istotnie różne sposoby:

Publish/subscribe (pub/sub) - celem jest temat (topic); wszyscy konsumenci zarejestrowani w danym temacie otrzymują każdy wysłany do niego komunikat; można to porównać do stacji rediowej nadającej na danej długości fali
Point-to-point (PTP) - celem jest kolejka (queue); każdy komunikat jest konsumowany dokładnie raz przez jednego z konsumentów; można to porównać do automatycznej sekretarki, w której odsłuchanie wiadomości ją usuwa

Model programistyczny

należy przez JNDI odnaleźć ConnectionFactory
przy jego pomocy tworzony jest obiekt Connection
przy pomocy którego należy utworzyć obiekt Session
ponownie przy pomocy JNDI trzeba odnaleźć cel (Topic lub Queue)
przy pomocy sesji oraz celu tworzony jest producer (Producer) lub konsument (Consumer)
producer/konsument wysyłają lub odbierają komunikaty

PARENT INTERFACE	POINT-TO-POINT	PUB/SUB
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Destination	Queue	Topic
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver QueueBrowser	TopicSubscriber

Ciekawostki

Klient kolejki może przeglądać wiadomości bez ich usuwania (QueueBrowser).
Wiadomość może przenosić pewne informacje w nagłówkach. Konsumer może zarządać otrzymywania jedynie wiadomości, których nagłówki spełniającej pewne kryteria (message selector).
Producent może utworzyć tymczasowy cel związany ze swoim obiektem Session i przekazać go konsumentowi w nagłówku JMSReplyTo. Konsument odpowiadając powinien zadbać, aby producer wiedział której wiadomości dotyczy odpowiedź. Może to zrobić ustawiając nagłówek JMSCorrelationID.
Klasy QueueRequestor i TopicRequestor implementują powyższy pomysł w blokujący sposób.
Kolejność komunikatów nie jest zagwarantowana.

Przykład

Strona HTML zawiera formularz pozwlający podać liczbę wysyłanych komunikatów i wybrać czy stosować komunikację PTP czy Pub/sub. Informacje z formularza są odczytywane przez serwlet, który wysyła wskazaną liczbę komunikatów do odpowiednio kolejki lub tematu. Do każdego komunikatu dołączana jest informacja o tymczasowej kolejce, przez którą serwlet oczekuje odpowiedzi. Po wysłaniu wszystkich komunikatów serwlet odbiera odpowiedzi zakładając, że i zarówno kolejka jak i temat mają po dwóch odbiorców. Odpowiedzi są wyświetlane na wynikowej stronie HTML. (Uwaga: trzeba sobie wyedytować stałą deploy.dir w build.xml)

Message-Driven Beans

tutorial (część 2 lekcje 5,6 i 7)

Zadanie

Proszę odnaleźć jak osadzić kilka beanów mając jedną klasę.