Enterprise JavaBeans 3.0: Ziarna sesyjne

Mała dygresja. Naukę EJB 3.0 rozpocząłem od przeczytania Simplified API dostępnego na stronie http://java.sun.com/products/ejb/docs.html. Przyznam, mimo że rzeczy fajne, to spać mi się chciało nie raz. Teraz przerzuciłem się na EJB in Action wydawnictwa Manning. Czyta się dużo przyjemniej, wszystko jest fajnie objaśnione. To co będziecie mogli znaleźć u mnie to w dużej mierze sedno informacji zawartych w tej książce jak i innych znalezionych na sieci, czy zdobytych własnym doświadczeniem. Na tę chwilę - naprawdę warto kupić tę książkę. Recenzję napiszę po przeczytaniu całości.

Aby dobrze zrozumieć czym są stanowe i bezstanowe ziarenka, warto nauczyć się czym w ogóle są session beans i co nam oferują...

• klienci - wywołać wspomniane ziarna może aplikacja desktopowa w Swingu, aplikacja webowa (np. JSP, JSF, servlet), czy nawet aplikacja .Net'owa korzystając z Web Service'u.
  
• współbieżność i bezpieczeństwo wątków - tworząc aplikacje serwerowe liczymy się z tym, że będą one pracowały nawet dla tysięcy użytkowników. Ale my przecież mamy wiele komponentów, ziarna stanowe, bezstanowe, interceptory. Kontener automagicznie zadba o to, aby tylko i wyłącznie jeden wątek miał dostęp do danego beana. W przypadku gdy wystąpią dwa jednoczesne wywołania kontener rzuci wyjątek javax.ejb.ConcurrentAccessException (co może się zmieni w Java EE 6 bo nie wszystkim podobają się te ograniczenia).
• zdalne wywoływanie - ziarna sesyjne mogą być wywoływane zdalnie w dwojaki sposób, poprzez RMI (Remote Method Invocation) lub web service'y. Co ważne, nie trzeba przy tym nic konfigurować oprócz 1 (słownie: jednej ;-)) linii adnotacji.
• transakcje i bezpieczeństwo - czyli Java Persistence API (do omówienia innym razem) i (dzięki oficjalnemu standardowi) wszystkie bajery dostępne wraz z Java EE.
• programowanie aspektowe i "usługi czasowe" - interceptory pozwalają na wywoływanie określonych zadań w momencie wywołania beanów, czy konkretnej metody danego ziarna. Jednocześnie nie łączą się bezpośrednio z nimi co pozwala na redukcję powtarzającego się kodu. Możliwe jest także wiązanie ziaren ze schedulerami (jak to będzie po polsku?).
  

Każde ziarno sesyjne składa się z dwóch nierozłącznych rzeczy:

• interfejs biznesowy - musi być przynajmniej jeden, może być lokalny lub zdalny, klienci nie mogą odwoływać się do konkretnych implementacji. Swoją drogą wartą tę regułę zastosować do każdego aspektu programowania. Pozwala to na modyfikację implementacji bez obawy, że wyrządzimy komuś krzywdę choćby brakiem wstecznej kompatybilności.
• implementacja - konkretny Plain Old Java Object (POJO), czyli zwykła klasa Java z dodanymi adnotacjami. Adnotacje EJB nie nie mają znaczenia dla JVM, są one istotne dopiero w momencie uruchomiania EJB w/na kontenerze. Bean nigdy nie może być klasą abstrakcyjną.

Parę zasad:

• Ziarno musi posiadać bezparametrowy publiczny konstruktor. Zadeklarowany jawnie lub nie.
• Ziarno może rozszerzać inne ziarna, ale co z adnotacjami? Są ignorowane oprócz adnotacji dotyczących cyklu życia, wstrzykiwania zależności czy zasobów.
  
• Metody biznesowe nie mogą zaczynać się od ejb. Muszą być publiczne, a nie mogą być finalne i statyczne. Metody oznaczone jako zdalne czyli @Remote - ich argumenty i zwracany typ musi implementować java.io.Serializable (ponieważ obiekty przesyłane zamieniane są w strumienie bajtów, dlatego warto uważać, aby nie były to duże obiekty).
  

Interfejs biznesowy to po prostu Plain Old Java Interface (POJI) z dołożoną adnotacją. Dane ziarno może posiadać wiele interfejsów, ale chociaż jeden musi być interfejsem biznesowym.

PS. Czy uważacie, że spolszczanie nazw komponentów EJB ma sens?