Z Pro JPA 2: zapytania natywne w SQL vs JP QL i peany nt. WAS V7

Lektura książki Pro JPA 2: Mastering the Java Persistence API z Apress trwa i nie przestaje mnie zdumiewać. Może nawet nie chodzi o nią samą, ale o to, co ma JPA2, co sprawia, że to właśnie sama specyfikacja mnie tak zdumiewa. Niektóre rzeczy były już w JPA1, więc tym bardziej lektura Pro JPA2 sprawia mi tyle przyjemności, bo co strona, to coś nowego. Pisałem, że mam w zwyczaju oznaczać sekcje książki do dogłębniejszego zbadania i kiedy zwykle w książkach jest kilka akapitów per rozdział, tak w Pro JPA2 są to prawie całe strony (!) "Prawie robi różnicę", ale jak by tego nie wartościować, materiału do przetrawienia jest cała masa.

Kiedy to piszę, zaczynam zastanawiać się, czy mógłbym tę książkę polecić adeptom JPA. Książka zakwalifikowana jest dla średniozaawansowanych - User level: Intermediate. Z jednej strony jest w niej wszystko, co poleciłbym początkującym, ale z drugiej jest tego tyle, że czytanie specyfikacji byłoby łatwiejsze - nie ma tam tylu dywagacji. Owe dywagacje sprawiają, że książka należy do obowiązkowych lektur każdego programisty JEE i nie ma co jej porównywać ze specyfikacją, ale jeśli mi rozdział (około 30-40 stron) zajmuje 3-4 dni, aby całość przetrawić, to jak tu polecić ją początkującym?! Serca nie mam?!

Jestem przy rozdziale 11. "Advanced Topics" (strona 333) i mam wrażenie, że czytam ją całe wieki. Z jednej strony, ciągnie mnie do niej, aby poznać więcej, z drugiej zaczynam powątpiewać w sens tak kurczowego się jej trzymania i dobrnięcia do końca. Nie będę ukrywał, że mnie trochę zmęczyła. Coś mi mówi, że gdyby była podzielona na dwie części, byłoby ją przyjemniej czytać. Przypomina mi "Wprowadzenie do algorytmów" Cormena i in., gdzie można znaleźć wszystko o algorytmach i faktycznie poleca się ją początkującym, ale przebrnięcie przez nią zabiera wieki. Fajnie, że można wszystko znaleźć w jednym miejscu, ale nawet najbardziej wytrwali padają w połowie i tylko zdrowy rozsądek podpowiada, że po zakończeniu satysfakcja gwarantowana. Wiedzy po pachy i aż by się chciało przeskoczyć kilka stron, aby mieć to za sobą.

Możnaby zapytać, czy warto tak się katować czytaniem, skoro czytanie powinno sprawiać przyjemność, a z moich słów można wyczytać ból i cierpienie. Możnaby to porównać do wyjścia na siłownię, bieżnię, wiosła, basen w wydaniu zaawansowanym. Wiemy, że będzie bolało i ma boleć, bo bez tego nie będzie wyników. Podobnie jest z Pro JPA 2 (i było z Cormenem) - bolało, ale ostatecznie wiedza była ponadprzeciętną i nawet, jeśli wszystkiego się nie spamiętało, to wiedza, że tam to jest nie raz uratowała tyłek. Bolało i pewnie nie raz jeszcze zaboli, ale lepsze to, kiedy chcemy, niż później podczas projektów, których jedynym rezultatem i tak jest zatonięcie, tyle że okupione większymi stratami i ślęczeniem po nocach (czego nikomu nie życzę).

Wszedłem w temat zaawansowanego JPA, w świat zapytań natywnych w SQL. W JP QL naszym modelem jest model obiektowy, a w SQL model relacyjny (czy jak to ostatnio ujął Michał M. na spotkaniu Warszawa JUG - tabelkowy). Wybór należy do piszącego zapytanie, do czego mu bliżej - obiekty czy tabelki. Co mnie jednak dzisiaj niezwykle przyjemnie zaskoczyło, to fakt, że bez względu na wybór języka zapytań, programista i tak korzysta z tych samych obiektów - wciąż mamy javax.persistence.Query lub wprowadzone w JPA2 - javax.persistence.TypedQuery (!) Czyż to nie jest wspaniałe w tej specyfikacji, że bez względu na język SQL vs JP QL zmiana w wielu przypadkach odbywa się bez zmiany kodu?! Kiedy dodam do tego, że wprowadzenie zapytań nazwanych (mianowanych?, ang. named queries) umożliwia nadpisywanie ich przez deskryptor persistence.xml, wtedy można do zespołu wdrożyć gościa, którego zadaniem będzie optymalizowanie zapytań. Pasuje mu pisać w SQL, niech będzie, woli podciągnąć się z technologii JEE, wchodzi w JP QL. Najważniejsze, że nie trzeba schodzić na poziom JDBC, aby tworzyć wysokowydajną obsługę danych w bazie. Programiści nie zmieniają swoich konstrukcji programistycznych i prą do przodu, a ów człowiek od zapytań, aka człowiek-pytajnik, optymalizuje zapytania w cieple domowego kominka. Niby oczywiste, ale dla mnie niezwykle odświeżające. Kiedy dodam, że wynik zapytania, to wciąż encje zarządzane przez kontekst utrwalania, wtedy świat staje się ułożony. Pamiętajmy jednak, aby zapytanie SQL pobierało całość danych z bazy danych, bo w przeciwnym wypadku, część danych nie spłynie do encji i podczas zatwierdzenia transakcji, albo przy javax.persistence.EntityManager.flush() dane zostaną wyczyszczone (zamazane pustymi wpisami). Zapewnie nie byłoby to czymś, czym chcielibyśmy się pochwalić klientowi ;-)

Chciałoby się popróbować z JPA2 i w zasadzie każdy może. JPA2 jest częścią JEE6, ale może żyć i bez niej. Jak to miało miejsce w JPA1, tak i w JPA2, uruchomienie w samodzielnych aplikacjach czy wręcz środowiskach zubożonych, np. w wersji wcześniejszej JEE5, jest jak najbardziej możliwe i wspierane specyfikacyjnie. Bodajże wczoraj czytałem zajawkę o wsparciu JPA2 przez Hibernate 3.5 CR1, więc pasjonaci Hibernate mają możliwość, a Ci spoza jego strefy wpływów mają do wyboru referencyjną implementację JPA2 - EclipseLink, albo nieodstającego od peletonu Apache OpenJPA. Zdaje się, że Hibernate, który miał niebagatelny wpływ na specyfikację JPA, zaczyna oddawać pola konkurencji. Mamy wybór, a to jest najważniejsze i w sumie (początkowo) nie ma znaczenia, co działa pod spodem.

Ostatnie tygodnie spędziłem nad redbookiem (książki o technologiach IBM) dotyczącym IBM WebSphere Application Server V7 Feature Pack for Service Component Architecture (w skrócie SCA FeP). Zajmowałem się częścią administracyjną, która jest niezwykle prosta, zakładając znajomość administacji IBM WebSphere Application Server V7 samą w sobie. Największym wyzwaniem było stworzenie bogatej technologicznie aplikacji SCA, ale kiedy okazało się, że wraz z SCA FeP przychodzi wiele przykładów, temat był do obsłużenia w ciągu tygodnia, dwóch (niestety, jak to zwykle bywa, sam rozruch trwał prawie 2 miesiące - czas Nowego Roku nie sprzyjał rozpoznaniu terenu).

Jeśli ktokolwiek parał się z SCA, to wie, że jedną z darmowych implementacji jest Apache Tuscany. I SCA FeP jest po prostu opakowaniem Tuscany w odpowiednie rozszerzenia WASowe. Podobnie było z EJB3 czy Web Services z JEE5 dla WAS 6.1. Było, ale kto tego używał? Na moje nieszczęście niewielu. Niestety, ale produkty stosowe, np. IBM WebSphere Process Server V6.2 nie wspierały tych rozszerzeń, więc w produkcyjnych środowiskach, gdzie królowało SCA i WS-BPEL z WPSem, o JEE5 można było zapomnieć chyba, że przez wykonywanie zdalnych usług Web Services, ale to zawsze można.

Niezwykłem do wychwalania produktów mojego pracodawcy obawiając się oskarżeń, że jest to spowodowane głównie, gdzie pracuję, a nie zaletom technologicznym i jakoś tak trwało, że ja swoje, a IBM swoje - technologicznie, oczywiście. Z pewnością na moją decyzję miała również wpływ cena, która zwykle w naszych (=moich i czytelników mojego bloga) rozwiązaniach oscylowała głównie wokół bezwzględnego zera, ze względu na użycie produktów darmowych, otwartoźródłowych. Kolejnym powodem, może nawet ważniejszym, było opóźnienie technologiczne w porównaniu z darmowymi rozwiązaniami. Kiedy królowało JEE5 najnowsze wydanie IBM WebSphere Application Server V6.1 to wciąż jedynie (?) J2EE 1.4 z rozszerzeniami do EJB3 i Web Services. Dobrze, że WAS 6.1 to OSGi i dał tym samym możliwość zabawy z nowościami JEE5 przez rozszerzenia zwane Feature Packs. Zbierając to wszystko, niewiele można było u mnie znaleźć o produktach z rodziny IBM WebSphere mimo, że duża część mojego czasu była konsumowana właśnie przez nie.

I tak trwałem w tym stanie zawieszenia między rozwiązaniami OSS, a IBM, aż do grudnia 2009, kiedy pojawiły się produkty na bazie WASv7. Najnowsze wydanie WAS V7 zmienia diametralnie oblicze rynku rozwiązań JEE. W końcu mam(y) wsparcie JEE5 z JSE6 i OSGi pod spodem. To się musi podobać, szczęśliwcom, których firmy weszły w tą wersję. Nie ma wciąż wielu produktów realizujących JEE6, więc sprawa nabrała rumieńców i moloch typu IBM w końcu dotrał do punktu, w którym WAS V7 wybroni się technologicznie z każdego przetargu. W końcu! Sprzedawcom na pewno zrobiło się lepiej/łatwiej.

Jeśli ktokolwiek zadaje sobie pytanie, po co to piszę i czy ma to jakikolwiek związek z JPA2, albo innymi specyfikacjami wokół JEE, to śpieszę donieść, że pojawiły się dwa otwarte programy IBM WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0 Open Beta. Z nimi, pod płaszczykiem nauki WAS V7 możemy poznawać nowości JEE6 i OSGi Enterprise z wykorzystaniem Apache OpenJPA 2 i Apache Aries. Czyż nasze administracyjno-programistyczne boje z WASem, nie wydają się być od razu przyjemniejsze? W końcu na coś się zda nasz trud i pot. Jeszcze nie tak dawno, zapisałem się do grupy Apache Aries, aby śledzić poczynania w kontekście korporacyjnego OSGi, gdzie łączy się JEE i OSGi w spójną całość, a tu IBM wyjeżdża z możliwością uruchomienia obu na WAS V7. Niezwykłem wychwalać WASa, bo do wersji 6.1, był po prostu znośny, gdzie moja nauka specyfikacji, to zawsze był krok przez nim. Teraz, z WAS V7, sprawa w końcu przybrała inny obrót - teraz ja muszę nadgonić, bo mam go z przodu. Biorąc pod uwagę inne zalety WAS V7, mogę z czystym sumieniem polecić go jako ten serwer aplikacyjny do rozwiązań komercyjnych. Po 4 latach pracy w IBMie, w końcu mogę odetchnąć, że ja też już mogę bawić się najnowszymi zabawkami i jeszcze mi za to płacą! I to jest w tym wszystkim dobre. Jeszcze tylko niech IBM WebSphere Process Server podskoczy do SCA 1.0 i będzie naprawdę cacy. Na razie ni widu, ni słychu.

A czy Wam też płacą za przyjemności w pracy, czy się wciąż katujecie niszowymi rozwiązaniami?! Wytrwałości. I Wam się też, kiedyś powiedzie! ;-)

p.s. Ci, którzy dobrnęli do końca, mogą odetchnąć i z czystym sumieniem oddać swój głos na Notatnik w konkursie Bloger 2009 Roku. Będzie tego więcej.