Enterprise JavaBeans 3.0: Wprowadzenie

Po co nam biznesowe ziarna javowe? Ano po to by było nam lżej. Każdy z nas prędzej czy później zmierzy się z aplikacją, która będzie musiała działać dla wielu użytkowników/zapytań itd., być dobrze zabezpieczona, obsługiwać różnego rodzaju błędy, wyjątki, sytuacje, przypadki, być łatwa w utrzymaniu, rozwoju itd. itp. Można by tak wymieniać i wymieniać. Z pomocą przychodzi nam właśnie EJB. Jest to standard, rozwijany przez społeczność Javy, który ma na celu pomóc developować aplikacje m.in. działające na serwerach aplikacji: Tomcat, GlassFish, JBoss itd., i zapewnić nam "łatwy" rozwój tej aplikacji, jej przenośność pomiędzy różnymi serwerami oraz zapobiec wymyślaniu kolejnego koła. Kołem tym jest zapewnienie bezpieczeństwa, transakcyjności, skalowalności, obsługi błędów... Tak, jest to kolejny framework, ale wart uwagi ze względu na oficjalny standard oraz możliwość interakcji z innymi framework'ami np. Springiem.

Na Enterprise JavaBeans 3.0 składają się:

• Session beans - ziarna sesyjne
• Message-driven beans - ziarna sterowane komunikatami
• Interceptors - interceptory dla ziaren sesyjnych

i tak trochę osobno:

• Entities - encje

Od wersji EJB 3.0 encje nie są już komponentami biznesowymi. Zostały wydzielone do Java Persistence API (JPA) i można ich używać także w aplikacjach desktopowych np. do komunikacji z lokalną bazą danych.

Głównym komponentem EJB jest klasa komponentu biznesowego. Aby klasa mogła nim być musi spełnić parę warunków:

• musi być określony typ ziarna - w pliku XML (deskryptorze wdrożenia) lub (i to jest super ;-) ) klasa musi zostać zadnotowana jako utrzymująca stan @Stateful lub bezstanowa @Stateless.
• musi posiadać interfejs biznesowy oznaczony jako lokalny @Local (domyślnie) lub zdalny @Remote. Jeśli klasa implementuje jeden interfejs nie musimy podawać żadnej adnotacji czy definiować tego w pliku xml. Jeśli jest ich więcej, każdy musi być oznaczony jako interfejs biznesowy, oczywiście interfejs nie może być jednocześnie zdalny i lokalny. Następujące interfejsy są wykluczone z określania czy dany interfejs jest biznesowy: java.io.Serializable oraz java.io.Externalizable.
• interfejs biznesowy nie może rozszerzać javax.ejb.EJBObject i javax.ejb.EJBLocalObject.

Oczywiście interfejsy mogą rzucać wyjątki, ale nie powinien to być java.rmi.RemoteException, ponieważ ten wyjątek już jest opakowany przez EJBException, a zajmie się tym kontener, czyli serwer aplikacji.

Kolejną bardzo ważną i fajną rzeczą jest Dependency Injection, czyli wstrzykiwanie zależności. W EJB 2.1 programiści byli zmuszeniu korzystać z JNDI (Java Naming and Directory Interface), jest to usługa, która pozwala przeszukiwać klasy, zasoby itp. Musieli oni przy tym pisać dużo zbędnego kodu i właśnie w ziarnach sesyjnych odwoływać się do konkretnych ziaren, zasobów. W EJB 3.0 kierunek został odwrócony. Wystarczy, że podacie nad danym interfejsem adnotację @EJB, a to kontener zajmie się znalezieniem odpowiedniej implementacji i wstrzyknie ją w beana. Podobnie jest z innymi zasobami, ale tam używana jest adnotacja @Resource.

W każdym przypadku zamiast adnotacji, można użyć konfiguracji w pliku xml. Jeśli obawiacie się, że to nie jest takie super, bo zapytacie: Co jeśli wprowadzę w adnotacjach konfigurację projektu, po czym przeniosę ją na inny serwer aplikacyjny z innymi ustawieniami? Można wtedy użyć deployment descriptor'a, czyli pliku ejb-jar.xml i tam zminić konfigurację :-)

Skoro tyle razy pojawił się wyraz biznesowy to musi to być fajne i na czasie ;-)