Artykuły tematyczne

Artykuł przedstawia możliwości najnowszej, szóstej, wersji technologii Java Enterprise Edition (Java EE). Wersja ta wprowadziła wiele poważnych przekształceń, dzięki którym Java EE zostało znacznie unowocześnione. Poprawiono funkcjonalność technice, kładąc jednocześnie duży nacisk na intuicyjność zastosowania, elastyczność.
Przyglądając się użyteczności JEE 6, będziemy śledzić proces budowy przykładowej aplikacji, która zade­monstruje nowe interface’y programistyczne i rozwiązania architektoniczne.
Autor:Piotr Kochański
Źródło: sdjournal.org

Wprowadzenie Java EE w wersji pięć zaowo­cowało usunięciem najważniejszych pro­blemów, z którymi borykali się programi­ści aplikacji serwerowych. Największy na­cisk położono wówczas na dopracowanie naj­bardziej nielubianej technologii JEE – kom­ponentów EJB.
Komponenty EJB są właśnie zwyczajnymi klasami Java (ang. Plain Old Java Objects
- POJO), a cała konfiguracja modułu EJB może być zrealizowana przy pomocy meta­danych (ang. annotations), zamiast pliku kon­figuracyjnego. Komponenty encyjne EJB, od­powiedzialne we wcześniejszych wersjach JEE za komunikację z bazą danych, nie zostały satysfakcjonującym rozstrzygnięciem i zastąpiła je nieporównywalnie lepsza technika: Java Persistence API.
Znaczącą innowacją było wprowadzenie wygodnego interfejsu programistycznego na potrzeby usług sieciowych. Technika JAX­

Powinieneś wiedzieć:
• Czytelnik powinien znać podstawy języka Java oraz technice Java EE.
WS, korzystająca z dobrodziejstw konfigura­cji przy pomocy metadanych, zastąpiła trud­ne w użyciu interfejsy SAAJ i JAX-RPC. Za­dbano również tym razem o to, aby usługi sie­ciowe JAX-WS z powodzeniem komunikowa­ły się z usługami pisanymi w innych technolo­giach, głównie .NET.
Java EE pięć była krokiem ewolucyjnym, nie rewolucyjnym. Poprawiono to, co tego wy­magało, a te elementy technice, które spe­cjalnie nikomu się nie naraziły, pozostawiono bez zmian. Charakterystyczny był priorytetowo brak niebagatelnych przeróbek w warstwie webowej technice Java EE.
Wprowadzenie Java EE 6 jest posunięciem znacznie radykalniejszym. Poza przemian ty­powo ewolucyjnych, ulepszających istniejące techniki – na przykład wprowadzenie Ja­va Persistence API 2.0 – przedefiniowano zu­pełnie sposób patrzenia na tworzenie i wdra­żanie aplikacji, projektowanie architektury czy wręcz na strukturę samego serwera apli­kacyjnego.
Zmiany te nie wzięły się znikąd. Przede wszystkim w świecie IT jest bardzo wyraź­ny trend używania coraz powszech­niej złożonych programów internetowych (ang. Rich Internet Applications), co stwarza, że webowy interfejs użytkownika odgrywa co­raz większą rolę. W rezultacie potrzebna jest technologia, która maksymalnie ułatwia two­rzenie takich aplikacji. A przy tym metodę budowania architektury programów, wzorce projektowe przeszły bardzo istotną ewolucję, która musiała odnaleźć odbicie po stronie Java EE.
Twórcy szóstej wersji Java EE, opracowu­jąc nową specyfikację, wzięli sobie do ser­ca potrzeby programistów, uwzględnili do­świadczenia najlepszych i najbardziej spraw­dzonych istniejących rozwiązań, takich jak Spring Framework, JBoss Seam czy Google Guice. Zobaczmy teraz, jaki jest efekt ich wy­siłków.

Przykładowa aplikacja
żeby dobrze poznać możliwości Java EE 6, utworzymy, wdrożymy i przetestujemy apli­kację webową Todo, służącą do kontrolowania listą rzeczy do zrobienia. Umożliwia ona doda­wać użytkowników , a oprócz tego przypisywać im za­dania. Można też wyświetlić listę zadań i użytkowników.

Aplikacja jest dość prosta, ale pozwoli nam dobrze zrozu­mieć omawiane techniki, pokazując ich wykorzystanie w konkretnej sytuacji.
Kolejność omawiania technologii będzie odpowiadała ich miejscu w cyklu tworzenia aplikacji. Rozpoczniemy od modelu dome­nowego programów, który znajduje indywidualne odbi­cie w warstwie trwałego przechowywania da­nych, następnie przejdziemy do implemen­tacji logiki biznesowej przy pomocy kompo­nentów EJB, a na końcu zajmiemy się inter­fejsem użytkownika.

Java Persistence API 2.0
JPA 2.0 jest konsekwentnym krokiem w stro­nę zaprojektowania standardowego i funkcjonal­nego mostu relacyjno-obiektowego dla apli­kacji Java. Dodano do technologii parę drob­nych udogodnień, między innymi:
• usuwanie osieroconych rekordów w bazie danych, w przypadku gdy został usunięty rekord pełniący rolę rodzica w relacji;
• ułatwiono modelowanie kolekcji obiek­tów – nie ma już potrzeby tworzenia do­datkowej, czasem zupełnie zbytecznej, encji JPA wraz z odpowiednią relacją;
• rozbudowano język zapytań Java Persi­stence Query Language (JPQL) o nowe użyteczne elementy.

Ukazały się też z dawna wyczekiwane po­ważniejsze zmiany, przede wszystkim inter­fejs zapytań Criteria, znany dobrze użyt­kownikom Hibernate.
Zapytania Criteria są konstruowane z obiektów Java, są dzięki temu silnie typo-wane, w odróżnieniu od zapytań JPQL, które są łańcuchami znaków. Znakomicie ułatwia to powstawanie złożonych, dynamicznie budo­wanych zapytań czy refaktoryzację aplikacji i, bez wątpienia, koryguje wydajność programów.
Drugą znaczącą zmianą jest możliwość pe­symistycznego blokowania rekordów. JPA 1.0 pozwalał wyłącznie na optymistyczne bloko­wanie rekordów, stosując mechanizm wersjonowania rekordów. JPA 2.0 umożliwia także na stosowanie blokad pesymistycznych, czyli faktycznego zablokowania dostępu do rekordu w bazie danych.
Budowę programów Todo rozpoczniemy od modelu domenowego, opisującego najważniej­sze jej szczegóły. Zadanie do zrobienia repre­zentuje encja Task, użytkownika encja User. Co więcej możemy zadaniom przypisywać kategorie (encja Category) , a oprócz tego dodawać do nich załączniki, opisywane klasą Attachment.
Listing 1 przedstawiający encję Task. Ponieważ za­łączniki interesują nas wyłącznie jako część za­dania, to nie posiada powodu wytworzyć dla nich en­cji i relacji między nią a Task. Wykorzystujemy więc uproszczony metodę definiowania pola ty­pu kolekcja. W JPA 2.0 nie musimy wyprodukować, sztucznej w tym kontekście, relacji – wystar­czy przy polu attachments dodać metadane @ElementCollection@CollectionTable(name = „task_attachments”), a mechanizm JPA bę­dzie sam dbał o zapisywanie do bazy danych od­powiednich rekordów. Po stronie skryptu Java po prostu używamy obiektu typu Set.

Klasa Attachment (Listing 2) jest bardzo prosta i zawiera wyłącznie raport najmniejszych elementów doty­czących wyglądu pól w podstawie danych, w szcze­gólności pole content jest zadeklarowane ja­ko pole stylu BLOB o wielkości 512 kB.
Metadane @Entity, @Id, @GeneratedValue są standardowymi detalami konfiguracji JPA oznaczającymi, stosownie, że: ma-my do czynienia z encją JPA, pole taskId re­przekazuje klucz priorytetowy w tabeli od­powiadającej encji Task, a jego wartość bę­dzie generowana domyślnym mechanizmem dla określonej bazy danych. Z kolei @Column i @Temporal uściślają wygląd schematu ba­zy danych.
Oprócz metadanych konfigurujących en­cję Task z punktu widzenia mechanizmu trwałości, znajduje się tam także wiele metada­nych związanych z inną, zupełnie nową tech­nologią.

Walidatory
Walidatory (ang. Bean Validation) dają nam ustandaryzowany sposób na sprawdzanie po­prawności danych. Jest to w sumie dość pro­ste rozwiązanie technologiczne, ale niezwy­kle pożyteczne.
Praktycznie największe dylematy z wali­dacją pojawiają się wówczas, gdy musi być ona przeprowadzana w kilku warstwach apli­kacji. Wyobraźmy sobie, że ewidentne dane są wprowadzane w warstwie interfejsu użyt­kownika, następnie przetwarzane poprzez warstwę logiki biznesowej i wreszcie trwale zapisywa­ne poprzez warstwę komuni­kacji z bazą danych. W za­sadzie powinieneś wali­dować informacje we wszystkich trzech miejscach, co oczy­wiście może spowodować duplikowanie kodu lub, co gorsza, pojawienie się róż­nych reguł walidacji w każ­dej z warstw.
Walidatory Java EE po­zwalają skonfigurować walidację w jednym miejscu. Odbywa się to po­przez dodanie odpowiednich metadanych przy wybranych polach klas.
Wybór miejsca centralnej konfiguracji wa­lidacji jest dość naturalny: klasy reprezentu­jące dane – w naszym przypadku są to encje JPA. W którejkolwiek warstwie programów bę­dziemy używać tych klas, to walidacja będzie za każdym razem przeprowadzana w ten sam sposób.
Do dyspozycji posiadamy szereg domyślnych walidatorów, między innymi @NotNull, @Size, @Min, których znaczenie jest dość oczywiste, prócz tego możemy spawdzać, czy pola typu Date albo Calendar reprezentu­ją datę później (@Future), bądź w prze­szłości (@Past). Niektóre metadane są zasto­sowane do encji Task (Listing 1).
Bardzo elastycznym walidatorem jest @Pa ttern(regexp=””), który kontroluje prawidłowość wartości pola względem podanego wyrażenia regularnego.
Można też generować swoje metadane walidujące, definiujące narzucane przez naszą firmę uwarunkowania poprawności danych. Łatwo można napisać, np, metadane @Pesel lub @Nip, sprawdzające poprawną wartość nume­ru PESEL lub NIP.

EJB 3.1
Posiadamy gotowy model domenowy aplika­cji Todo, czas go ożywić, dodając warstwę wykonującą na nim różnego typu opera­cje – logikę biznesową. Java EE zakłada, że do tego celu będą wykorzystywane kompo­nenty EJB. Kiedyś taki wybór był traktowa­ny jako zło konieczne, w większości też całkowicie ignorowano tę technologię, przede wszyst­kim ze względu na niewygodną konfigura­cję, trudności przy testowaniu i produkowaniu efektywnego modelu obiektowego. Dodat­kowo komponenty EJB musiały być wdra­żane jako osobne archiwa, co stanowiło nie­potrzebną komplikację w wypadku aplika­cji webowych.

Część problemów związanych z tą techno­logią rozwiązało wprowadzenie wersji EJB 3.0; najnowsza odsłona specyfikacji stawia kropkę nad i, dając nam do ręki narzędzie o bardzo dużych możliwościach (deklaratyw­ne zarządzanie transakcjami, klastrowalność, i tak dalej.), a równocześnie proste w użyciu i funk­cjonalne.
Pierwszym ułatwieniem jest brak koniecz­ności użycia interfejsów dla komponentów EJB o dostępie lokalnym (ang. No-interface view), wszelkie publiczne metody kompo­nentu są samoczynnie dostępne dla mieszkanie­nych kontrahentów.
Pojawił się też nowy typ komponentów sesyjnych – Singleton. Wszyscy nabywcy apli­kacji używają jedynie jednej instancji takiego komponentu, dzięki czemu łatwo produkować komponenty, które pełnią rolę schowków na informacje, przechowują ustawienia konfiguracyj­ne lub którekolwiek inne informacje, które powinny być współdzielone.
Singletony można konfigurować pod kątem zachowania w środowisku wielo­wątkowym. Domyślnie są one bezpieczne dla wątków, ale gdy upowszechniają one dane wyłącznie do odczytu, to można to zachowanie zmie­nić, z profitem dla wydajności aplikacji.
W komponentach EJB można produkować me­tody asynchroniczne, których wywołanie nie stwarza wstrzymania wątku kontrahenta. Meto­dy takie mogą lub nie zwracać wartości, lub zwracać obiekt java.util.concurrent.Futu re, dzięki któremu można stwierdzić, czy jest już dostępny wynik działania metody i go ściągnąć. Dotychczas jedynym mechanizmem asynchronicznym w EJB zostały komponenty nakierowane na komunikaty (ang. Message Driven Beans).
Znaczącym ułatwieniem dla programi­stów tworzących programy WWW jest moż­liwość wdrażania komponentów EJB w ar­chiwach WAR programów WWW (ang. war deployment).