Języki

Erudis - your road to knowledge
Komponenty EJB 3.1

Pojawił się nowy typ komponentów sesyjnych – Singleton. Wszyscy klienci aplikacji używają tylko jednej instancji takiego komponentu, dzięki czemu łatwo tworzyć komponenty, które pełnią role schowków na wspólne dane, ustawień konfiguracyjnych lub dowolne inne dane, które powinny być współdzielone.

W komponentach EJB można tworzyć metody asynchroniczne, których wywołanie nie powoduje wstrzymania wątku klienta. Metody takie mogą albo nie zwracać wartości, albo zwracać obiekt java.util.concurrent.Future, dzięki któremu można stwierdzić, czy jest już dostępny wynik działania metody i go pobrać. Dotychczas jedynym mechanizmem asynchronicznym w EJB było komponenty zorientowane na komunikaty (ang. Message Driven Beans).

Komponenty EJB można również wdrażać w ramach archiwów aplikacji WWW (ang. war deployment).

EJB Lite. Wiele typów aplikacji, zwłaszcza webowych, nie potrzebuje pełnej funkcjonalności EJB (na przykład integracji z CORBA, zdalnych interfejsów), stąd utworzenie uproszczonej specyfikacji, dzięki której użycie komponentów będzie proste i łatwe w nauczeniu się. Także twórcy serwerów aplikacyjnych czy webowych będą mieli łatwiejsze zadanie, przy implementacji nowego standardu.

Działanie kontenera EJB w trybie wbudowanym (ang. Embedded container). Nowy interfejs programistyczny pozwala na uruchomienie kontenera EJB i wdrożenie na nim komponentów z poziomu kodu aplikacji Java SE, ułatwi to bardzo testowanie komponentów EJB.

Dla komponentów EJB o dostępie lokalnym nie trzeba tworzyć interfejsu – jest on opcjonalny (ang. No-interface view), wszystkie publiczne metody komponentu są automatycznie dostępne dla lokalnych klientów.

Nazwy JNDI dla komponentów są ustandaryzowane, dzięki temu aplikacje będą bardziej przenośne między serwerami aplikacji.

Technologię EJB doprowadziła do stanu komfortu użycia wersja 3.0, ale wersja 3.1 przyniosła kilka wyczekiwanych funkcjonalności, powodując, że są one jak najbardziej sensownym wyborem przy projektowaniu aplikacji.

EJB proste w implementacji i konfiguracji i nie powodują szczególnych problemów wydajnościowych – typowo rozwiązanie oparte o „czyste” klasy POJO będzie wydajniejsze tylko o ok. 10%, co w praktyce nie ma znaczenia, zwłaszcza jeżeli weźmiemy pod uwagę ilość usług, jakie dostajemy używając EJB (klastrowanie, zarządzanie cyklem życia, transakcje, itp).