Enterprise JavaBean EJB 2.x oraz zmiany w standardzie dla EJB 3.0 Michał Stanek
Plan prezentacji Czym jest EJB Architektura aplikacji J2EE oraz kontener EJB Typy komponentów JavaBean EJB 1.0, EJB 2.x Wady EJB 2.x zmiany wprowadzone w EJB 3.0 Kilka przykładów
Czym jest EJB EJB jest częścią specyfikacji/platformy J2EE EJB komponent po stronie serwera EJB enkapsuluje logikę/obiekty biznesowe EJB ma uprościć proces wytwarzania oprogramowania EJB to również cienki klient Możliwość zakupienia gotowych komponentów EJB od innych dostawców
Architektura Aplikacji J2EE
Architektura aplikacji J2EE
Kiedy używa się EJB Aplikacja ma być skalowalna ( lokalizacja komponentów EJB jest transparentna dla klienta ) W celu zapewnienia integralności danych musimy wprowadzić transakcje Istnieje wiele różnorodnych klientów naszej aplikacji.
Kontener EJB
Czym zajmuje się Kontener EJB Izoluje EJB przed bezpośrednimi wywołaniami z zewnątrz (wszystkie wywołania są przechwytywane przez kontener) Zapewnia automatycznie: Persystencję obiektów Transakcje Bezpieczeństwo Kontener zarządza jednocześnie wieloma EJB (podobnie jak kontener servletów)
Rodzaje EJB Enterprise JavaBean Session Bean Entity Bean Message-Driven Bean Stateless Stateful CMP BMP
Session EJB Reprezentuje pojedynczego klienta aplikacji. Session Bean nie jest dzielony pomiędzy klientami. Session Bean nie jest persystentny ( istnieje second storage) Kiedy klient kończy połączenie Session Bean jest zwalniany (pooling, zwolnienie zasobu)
Stateless Session Bean Bean nie przechowuje stanu pomiędzy kolejnymi wywołaniami klienta W ramach wywołania bean może mieć stan, może korzystać z Entity Bean, zewnętrznych zasobów, itp Nie są nigdy zapisywane przez kontener Są lżejsze od Stateful Session Bean
Statefull Sesion Bean Pomiędzy kolejnymi wywołaniami klienta zachowywany jest stan konwersacji Jest bardziej obciążający dla kontenera
Entity EJB Entity Bean reprezentuje obiekt biznesowy. Entity Bean jest z natury persystentny (z reguły obiektowi Entity Bean odpowiada tabela w Relacyjnej bazie danych). Posiada klucz główny Może pozostawać w związkach z innymi Entity Beans Może być dzielony pomiędzy wielu klientów
CMP i BMP Entity Bean Bean Managed Persistency: Musimy sami oprogramować persystencję obiektu Container Managed Persistency: Kontener zajmuje się zapisem i odczytem beana z bazy danych Nie trzeba pisać nawet jednej linijki w SQL u Zapewniamy większą przenośność naszego Beana Aby zapewnić persystencję musimy dostarczyć jedynie Entity Bean Abstract Schema
Abstract Schema Definiuje jakie pola w Entity Bean są persystentne Określa związki Entity Bean z innymi obiektami Musimy podać nazwę Abstract Schema w deskryptorze wdrożenia Dla CMP Bean musimy za pomocą EJB QL zdefiniować każdą metodę find (oprócz findbyprimarykey)
Kiedy używać Entity Bean Bean reprezentuje obiekt biznesowy, a nie procedurę ( CreditCardBean, CreditCardVeriferBean) Stan obiektu musi pozostać persystentny
Message Driven Bean W odróżnieniu do poprzednich pozwala przetwarzać komunikaty asynchronicznie Działa podobnie do Listnera zdarzeń otrzymuje JMS message zamiast event Komunikat może być wysłany przez dowolny komponent J2EE (klienta, Enterprise JavaBeana, komponent Webowy) Klient nie wywołuje M-D Beana przez jakikolwiek interfejs. Każdy M-D Bean jest równoważny (jest bezstanowy) Jest efektywniejszy niż inne Beany nie jest podejmowana konwersacja z serwerem.
Ogólny proces tworzenia komponentu EJB Przygotowanie kodu źródłowego klasy Java, reprezentującej komponent EJB Utworzenie dwóch interfejsów Java, reprezentujących punkty kontaktu świata zewnętrznego z komponentem EJB: interfejs Home, służący do zarządzania cyklem życia komponentu EJB interfejs Remote/Local, służący do wywoływania metod logiki biznesowej komponentu EJB Przygotowanie XML-owego pliku konfiguracyjnego - deskryptora instalacji (Deployment Descriptor) Kompilacja całego przygotowanego kodu Java i utworzenie z niego pliku JAR/EAR o specjalnej wewnętrznej strukturze katalogów Umieszczenie przygotowanych plików w systemie plików serwera aplikacji; zarejestrowanie komponentu EJB
Implementacja EJB
Tworzenie Beana public interface Calculator extends EJBObject { int add (int a, int b) throws RemoteException; int subtract (int a, int b) throws RemoteException; } public interface CalculatorHome extends EJBHome { Calculator create() throws CreateException, RemoteException; }
Tworzenie Beana public class CalculatorBean implements SessionBean { private SessionContext ctx; public void setsessioncontext(sessioncontext s) {ctx = s;} public void ejbcreate() {} public void ejbactivate () {} public void ejbpassivate () {} public void ejbremove () {} public int add (int a, int b) { return a + b; } } public int subtract (int a, int b) { return a b; }
Tworzenie Beana <session> <ejb-name>calculatorejb</ejb-name> <home>com.example.calculatorhome</home> <remote>com.example.calculator</remote> <ejb-class>com.example.calculatorbean</ejb-class> <session-type>stateless</session-type> <transaction-type>container</transaction-type> </session>...
Przykładowy deskryptor wdrożenia
Historia EJB EJB 1.0 XML-owy deskryptor wdrożenia Transakcje na poziomie metod, zabezpieczenia Brak asocjacji CMP zależne od kontenera Specyficzna deklaracja finderów
Historia EJB EJB 2.x: CMR dla asocjacji Standaryzacja deskryptora wdrożenia dla CMP Wprowadzenie EJB QL Dodano Message Driven Bean
Wady EJB 2.x Brzydki styl programowania javax.ejb Bardzo złożony deskryptor wdrożenia Pomieszana implementacja sprawdzanych oraz nie sprawdzanych wyjątków Brak polimorfizmu Brak możliwości testowania poza kontenerem EJB QL zbyt ograniczony ( brak agregacji/projekcji, brak outer-join a, brak paginatora )
Założenia EJB 3.0 Redukcja liczby generowanych artefaktów Eliminacja konieczności dostarczenia deskryptora wdrożenia Umożliwienie generowania interfejsów bezpośrednio z klasy Beana Uproszczenie tworzenia Enterprise JavaBean Eliminacja implementowanych interfejsów
Założenia EJB 3.0 Uproszczenie tworzenia CMP Entity Bean Wprowadzenie dziedziczenia i polimorfizmu Rozszerzenie języka EJB QL m.in. o: Podzapytania Zapytania dynamiczne Projection Explicit inner oraz outer join Group by, Having Wsparcie dla natywnych wywołań SQL
EJB 3.0 Stateless Session Bean @Remote public interface Calculator { public int add(int x, int y); } public int subtract(int x, int y); @Stateless public class CalculatorBean implements Calculator { public int add(int x, int y) { return x + y; } public int subtract(int x, int y) { Return x y; } }
Stateless + generowany interfejs @Stateless public class CalculatorBean implements Calculator { public int add(int x, int y) { return x + y; } public int subtract(int x, int y) { Return x y; } }
Deskryptor wdrożenia
Co zrobiliśmy? Eliminacja Interfejsu domowego(home Interface) Obiekt jest zwykłym obiektem POJO (Plain Old Java Object) Tylko jeden artefakt Możliwość automatycznego generowania interfejsu Łatwość testowania za pomocą JUnit
Simpliefied Entity Bean @Entity(table="Aukcja") public class Aukcja { @PK (column="aukcjaid", generator="sequence") private Long id; @Attribute private String opis; @OneToMany (inverse="auction" order-by="data") private Set<Rachunek> rachunek = new HashSet(); @ManyToOne (fk="sprzedawcaid") private User sprzedawca @Attribute(formula="Select Max(R.Suma) from Rachunek R" + "where R.AukcjaID = AuctionID") private BigDecimal maxsumarachunku; } public BigDecimal getmaxsumarachunku() { return maxsumara }
Zalety Uproszone projektowanie oraz programowanie Możliwość użycia obiektów poza kontenerem Łatwość testowania Usunięcie konieczności wykorzystywania wzorca projektowego DTO (Data Transfer Object) BMP jest już w zasadzie bezcelowy
Mapowanie O/R oraz EJB QL Użycie metadanych do określenia mapowania Wprowadzenie polimorfizmu i dziedziczenia: Table per class Table per class hierarchy Rozszerzenie możliwości EJB QL m.in. o: Bulk update i delete Projection Group by, Having Podzapytania
Bulk update/delete DELETE FROM Klient k WHERE k.status = nieaktywny UPDATE Klient k SET k.status = nieaktywny WHERE c.zamowienia=0
Podzapytania SELECT dobryklient FROM Klient dobryklient WHERE dobryklient.zamowienia < ( ) SELECT avg(k.zamowienia) FROM Klient k
Podsumowanie Znaczna ewolucja poczynając od EJB 1.0 a kończąc na EJB 3.0 Uproszczenie modelowania złożonych systemów. Uniezależnienie się od konkretnych kontenerów serwletów. Skrócenie czasu wytwarzania oraz projektowania aplikacji. Łatwość testowania (możliwość pracy wg. Metodyki Test Driven Development) Resin kontener EJB 3.0
Literatura The J2EE 1.4 Tutorial JSR 220: Enterprise JavaBeansTM,Version 3.0 - EJB 3.0 Simplified API JSR 220: Enterprise JavaBeansTM,Version 3.0 - Persistence API From EJB to Hibernate to EJB 3 Gavin King (Jboss inc.) EJB 3.0 Work in progress Linda De Michiel (EJB 3.0 Spec Lead)
Literatura - książki Ed Roman Mastering Enterprise JavaBean 2nd edition Richard Monson-Haefel EJB 3RD EDITION