Tworzenie aplikacji Google Web Toolkit z Java Persistence API

Poznając Google Web Toolkit (GWT) coraz bardziej doskwierał mi brak środowiska, które umożliwiłoby mi tworzenie aplikacji z GWT wykorzystując przy tym JPA i inne technologie Java EE wraz z uruchomieniem całej aplikacji na serwerze aplikacyjnym Java EE. Niby wszystko było jasne, jak należy wszystko zestawić, ale nie mogłem się zebrać i w końcu to sprawdzić w praktyce. Przypadkiem natrafiłem na ciekawy artykuł o GWT i Apache Geronimo - Build an Ajax-enabled application using the Google Web Toolkit and Apache Geronimo, Part 1: Run compiled Google Web Toolkit applications on Geronimo. Nie mogłem wymarzyć sobie lepszego materiału do zgłębiania tajemnic GWT, co zmotywowało mnie do zajęcia się tematem bliżej. Zaraz zabrałem się za lekturę. Tak na marginesie muszę przyznać, że artykuł pojawił się w samą porę, bo nie tylko, że poznam GWT bliżej analizując przykład z artykułu, to jeszcze będę miał dobre przygotowanie na konferencję JavaTechConf 2007 w Krakowie pod koniec maja, gdzie właśnie prezentuję Apache Geronimo i jego wsparcie dla Java EE 5. Jeśli, więc pokażę technologie Przemysłowej 5-tki w połączeniu z GWT będzie to z pewnością prezentacja, na której po prostu warto być ;-) Mam wiele pomysłów na moją godzinną prezentację i mimo bardzo krótkiego czasu na jej poprowadzenie, do worka technologicznego na konferencję dorzucam również i GWT. Obym nie obiecał gruszek na wierzbie, bo mam już w nim Apache Geronimo, Apache Maven 2, TestNG, JPA i zapewne JSF 1.2 (w wykonaniu Apache MyFaces). Szkoda, że konferencja jest w tak odległym terminie, bo znając siebie, coś na pewno jeszcze dorzucę i zamiast godziny będę prezentował cały dzień.

Wracając do moich doświadczeń z GWT i JPA przez ostatnie kilka dni, było ich tyle, że postanowiłem je spisać i udostępnić jako kolejny artykuł - Tworzenie aplikacji Google Web Toolkit z Java Persistence API. Czytelnik znajdzie tam informacje potrzebne do zestawienia środowiska programistycznego do tworzenia aplikacji z GWT i JPA oraz Apache OpenJPA, Apache Derby, Dozer i Jetty wszystko zarządzane przez Apache Maven 2. W końcu udało mi się zapoznać z ostatnimi z tematów w GWT, m.in. serializacją, kontrolkami graficznymi GWT i obsługą zdarzeń. Zeszło mi się trochę z tym środowiskiem (bodajże 4 dni) i ciekawym bardzo komentarzy i uwag odnośnie zawartości merytorycznej artykułu. Coś wydaje mi się, że trochę dużo tego wyszło i mało kto dotrwa z lekturą do końca. Może powinienem rozważyć nagrodzenie najwytrwalszych?!

Dalsze możliwości rozwoju aplikacji to udoskonalenie wyglądu interfejsu użytkownika i podział projektu na oddzielne podmoduły (w sensie M2) - dla części GWT i JPA. Jeśli będą chętni do udostępnienia swoich zmian w tym kierunku z miłą chęcią opublikuję je w ramach artykułu.

A skąd pomysł na aplikację Rejestr Osób? W czasach otwierania teczek tego typu aplikacje przeżywają swój okres rozkwitu, więc i ja musiałem spróbować. Oczywiście jest to namiastka prawdziwej aplikacji, ale jej tworzenie w GWT sprawiło mi wiele przyjemności, może nawet tyle, że zastanawiam się, co miałoby mnie skłonić do napisania jej korzystając z JSF. Na prawdę zaczynam mieć coraz większe wątpliwości przed wyborem tej jedynej technologii przy następnych projektach - wydaje się, że GWT spełnia wszystkie wymagania stawiane współczesnym szkieletom programistycznym wliczając w to wręcz banalny sposób tworzenia zaawansowanych interfejsów użytkownika, udostępnienie funkcjonalności Ajax, możliwość wykonywania zdalnych usług i tym samym wykorzystania usług serwera Java EE, obsługę przycisku wstecz, itp. Będę musiał poświęcić kilka chwil na głośne rozważania na ten temat, bo teraz na gorąco, po pomyślnie zakończonej integracji GWT i JPA zdecydowanie byłobym za GWT. Dzięki Janek, Grzesiek i Marcin za pomysł aplikacji!

Na sam koniec wrócę jeszcze do mojego ostatniego wpisu o SCA - SCA - Service Component Architecture - zaczynam rozpoznanie czegoś całkowicie dla mnie nowego. Nie ukrywam, że liczyłem na pewnien odzew w tej kwestii, ale dyskusja jaka rozwinęła się przeszła moje najśmielsze oczekiwania. Bardzo dziękuję wszystkim za komentarze, które zamierzam wykorzystać studiując specyfikację SCA. Zanim na dobre zaangażowałem się w zestawianie środowiska z GWT i JPA, udało mi się zapoznać z kilkoma materiałami nt. SCA i jedną z cech, które niezwykle mi się podobały była możliwość podmiany modułu SCA dynamicznie podczas działania aplikacji. Wydaje mi się, że przykład prezentujący tę możliwość w połączeniu z GWT mógłby być niezwykle interesujący. Wyobraźmy sobie aplikację składającą się z kilku modułów SCA (wykorzystanych przez zdalne usługi GWT), która pracuje nieprzerwanie z możliwością dynamicznej podmiany modułu. W ogóle, tworzenie modułu SCA jest tak łudząco podobne do tworzenia usługi zdalnej w GWT, że trudno o nich czytać nie sądząc, że czyta się o jednym i tym samym. Dla dalszego zobrazowania roli SCA możnaby porównać ją z OSGi do budowania modularnych architektur. Jeśli OSGi pozwala na wyszukanie modułu i jego zarządzanie podczas działania aplikacji, to różnica między SCA polega na zasięgu takiej funkcjonalności - w OSGi wszystko dzieje się w ramach pojedyńczej wirtualnej maszyny podczas, gdy w SCA nie ma żadnych takich ograniczeń - miejsce uruchomienia nie implikuje dostępnych usług. Ciekawe tylko, czy faktycznie moje rozumienie roli SCA i OSGi jest słuszne? Dużo dobrych technologii powstaje i człowiek nic innego by nie robił, jak tylko się nimi bawił i rozpoznawał. A tu Panie Jacku coraz cieplej za oknem i komu chciałoby się przesiadywać przez komputerem?! Ech, byle do zimy! ;-)

Przepis na środowisko do praktycznego poznawania JPA

Właśnie ukończyłem pisanie kolejnego artykułu, który jest opisem moich doświadczeń z integracji różnych projektów w celu zestawienia środowiska dla urozmaicenia lektury specyfikacji JPA. Z jego pomocą zamierzam jednocześnie czytać i programować, tj. tworzyć własne komponenty encyjne oraz wykonywać testy jednostkowe z nimi w roli głównej.

Nie tak dawno pisałem (a może jedynie myślałem o tym) o popróbowaniu się z TestNG. Było to w momencie, kiedy powracałem do lektury specyfikacji Java Persistence API (JPA), więc pomyślałem o połączeniu przyjemnego z pożytecznym, czyli o możliwości jednoczesnego testowania tego, co czytałem. Można było również inaczej postawić problem - najpierw próbować się z JPA, a później szukać wyjaśnień jej działania wertując kartki specyfikacji. Tak, czy owak nie chciałem jedynie relacjonować specyfikacji JPA, ale również prezentować możliwe zastosowania. Sprowokowało mnie to do zestawienia środowiska, w którym będę tworzył moje komponenty encyjne i aplikacje korzystające z nich oraz posiadał mechanizm wykonywania testów. Skoro dotykałem JPA to konieczna była baza danych - padło na Apache Derby. Do tego dorzuciłem Apache Maven 2 jako narzędzie spinające całość (i dostarczające wielu niewykorzystanych acz wielce produktywnych funkcjonalności), z Eclipse IDE w tle, co ostatecznie przemieniło się w bardzo produktywne środowisko do poznawania JPA w niezwykle praktyczny sposób - tworząc testy jednostkowe w trakcie lektury specyfikacji.

Początkowo miała to być jedynie relacja z moich doświadczeń, ale nie długo trwało zanim zorientowałem się, że wielkość materiału przekracza ramy relacji i wymaga stworzenia artykułu, co uczyniłem.

Jest to środowisko, które uatrakcyjni moją lekturę specyfikacji. Robi się w końcu coraz trudniej i możliwość zobaczenia tego, co się czyta wierzę, że jest ciekawym pomysłem na niwelowanie potencjalnych wybojów. Konfiguracja środowiska z wykorzystaniem JPA z Apache OpenJPA i Apache Derby oraz Apache Maven 2 i TestNG zapewnia mi powtarzalność wykonywania testów i jest jednocześnie ciekawym urozmaiceniem pogłębiania znajomości JPA. Tak "uzbrojony" jestem gotów do podjęcia się wyzwania rozpoznawania specyfikacji Java Persistence API w praktyce!

Artykuł zatytułowany jest Java Persistence API z OpenJPA i Derby oraz TestNG z Eclipse IDE w tle.