Kolejne rozdziały specyfikacji EJB3 Simplified - Chapter 6 Message-Driven Beans oraz Chapter 7 Persistence

Wydawałoby się, że czytanie specyfikacji Java EE nie może być przyjemne. Tylko Ci tak twierdzą, którzy nigdy tego nie robili. Dla przykładu: wczoraj przeczytałem 2 rozdziały EJB3 Simplified - Chapter 6 Message-Driven Beans oraz Chapter 7 Persistence. Czy to dużo? Wydawać by się mogło, że tak, ale w sumie oba mają nie więcej niż...3 strony (!) Autorzy specyfikacji wzięli sobie do serca tytuł tej części specyfikacji EJB3 - Simplified. Dodać należy, że Java Persistence ma swoją odrębną specyfikację wynikającą z jej odmienności w stosunku do innych komponentów, więc rozdział 7 to tak na prawdę odwołanie do lektury EJB3 Core.

O czym, więc napisano w kontekście komponentu sterowanego komunikatami (ang. MDB - message-driven bean)?

W przeciwieństwie do komponentów sesyjnych, MBD wymaga, aby interfejs biznesowy był interfejsem wyznaczającym obsługiwany typu komunikacji, np. JMS przez javax.jms.MessageListener.

MDB musi implementować interfejs związany z obsługiwanym typem komunikacji bądź wskazać interfejs poprzez annotację @MessageDriven bądź deskryptor instalacji.

Klasa staje się komponentem MDB po udekorowaniu annotacją @MessageDriven lub poprzez definicję w deskryptorze instalacji. Koniec z implementacją interfejsu javax.ejb.MessageDrivenBean.

Metody zwrotne związane z cyklem życia komponentu MDB - wspierane zdarzenia to:

• tworzenie
• usuwanie

i przechwytywane metodami udekorowanymi annotacjami:

• @PostConstruct
• @PreDestroy
  

, odpowiednio.

Podobnie jak w przypadku komponentów sesyjnych, @PostConstruct wywoływane jest po stworzeniu instancji komponentu i DI, ale przed wywołaniem pierwszej metody biznesowej (co w przypadku MDB jest wywołaniem metody interfejsu wyznaczającego typ obsługiwanej komunikacji).

@PostConstruct oraz @PreDestroy wykonywane są w nieokreślonym kontekście transakcyjnym i bezpieczeństwa.

Podobnie jak w komponentach sesyjnych, DI następuje przed wywołaniem metod interfejsu komunikacyjnego bądź metod zwrotnych.

Podobnie jak w komponentach sesyjnych, interceptor @AroundInvoke jest dostępny dla MDB i definiowany jest bezpośrednio w klasie komponentu lub interceptorze i dołączany jest do wykonania metody interfejsu biznesowego.


W skrócie, poznanie zachowania komponentu SFSB pozwala na zapoznanie się z tematem zachowania pozostałych komponentów, w tym i MDB, stąd wiele zawartych tu informacji różni się wyłącznie asynchronicznym zachowaniem się MDB i zależnością między interfejsem biznesowym MDB, a interfejsem usługi komunikatów.

Do zobaczenia na spotkaniu!