29 stycznia 2007

Java Persistence API (JPA) - Chapter 1 Introduction

Lektura EJB3 Simplified za mną i długo wahałem się przed podjęciem kolejnej decyzji o następnej specyfikacji. Zawsze chciałem zajrzeć do EJB Core Contracts and Requirements, ale poza teoretycznym wzmocnieniem swojej wiedzy o EJB3, nie dowiedziałbym się niczego praktycznego, niczego nowego, czego nie dowiedziałem się z EJB3 Simplified. W międzyczasie miałem okazję zajrzeć do Java EE 5 Specification i wciąż oczekiwała mnie specyfikacja JavaServer Faces 1.2. I tak się zastanawiałem, aż kiedy przyszło do napisania aplikacji z użyciem JPA, gdzie nie mogłem poradzić sobie z ustaleniem konfiguracji dla servletu, który korzystał z @PersistenceContext. Do tego doszło zaproszenie do lektury Hibernate. Od Nowicjusza do Profesjonalisty i tak ostatecznie podjąłem decyzję o rozpoczęciu lektury specyfikacji Java Persistence API. Podobnie jak poprzednio z EJB3 Simplified, zamierzam przejść rozdział po rozdziale przez cały dokument, poznając tajniki JPA na bazie GlassFish (z TopLink jako dostawcą JPA), Apache OpenJPA oraz Hibernate.

Zaczynam od rozdziału wprowadzającego - Chapter 1 Introduction.

Dokument jest specyfikacją interfejsu publicznego Java do zarządzania zapisem (utrwalaniem) i mapowaniem danych obiektowych do/z postaci relacyjnej (ang. ORM - object/relational mapping) w Java EE oraz Java SE. I tu pierwsza ważna informacja - wspomniano o dwóch platformach, na których możliwe jest uruchomienie rozwiązań JPA - serwery aplikacyjne oraz najzwyklejsze aplikacje Java nie korzystające z ich usług. Z publikacją Java Persistence API (JPA) umożliwiono twórcom aplikacji Java korzystanie z ustandaryzowanego sposobu mapowania danych z/do bazy relacyjnej (podobnie jak JDBC jest ustandaryzowanym dostępem do bazy danych, tak JPA jest ustandaryzowanym mechanizmem operowania danymi relacyjnymi - przechowywanymi w bazie danych i pobranych za pomocą JDBC).

Wymagane jest, aby kontenery EJB3 obsługiwały JPA.

Wyraźnie zaznaczono wpływ istniejących projektów i specyfikacji na ostateczną postać JPA - Hibernate, TopLink oraz JDO (ang. Java Data Object). Przez wiele lat zarzucano specyfikacji EJB brak wykorzystania interesujących i sprawdzonych rozwiązań z innych projektów, wliczając wciąż mało popularną specyfikację JDO, która nie mogła zdobyć się na sławę równą Hibernate (podobnie jak C++ porównany z Java). Tym razem celem JPA było dostarczenie ustandaryzowanego API, które przybliża cechy wymienionych produktów i specyfikacji do szerszego grona odbiorców.

Lista osób biorących udział w tworzeniu specyfikacji JPA zamyka rozdział 1. (jest na niej wiele osób, które czynnie biorą udział w projektach otwartych, w tym Apache Geronimo oraz Apache OpenEJB).

p.s. Dziś po raz pierwszy doświadczyłem aktywności spamerów na własnej skórze - we własnym notatniku. Ostatnio doświadczyła tego załoga javalobby.org i po tym jak pojawiło się mnóstwo wiadomości z nielegalnymi odnośnikami Google wyłączył ich stronę z indeksowania (Rick na prawdę się tym przejął dedykując wiadomość o tym wydarzeniu i rozsyłając informację do użytkowników JavaLobby). W jeden dzień javalobby.org i mnóstwo artykułów Java zniknęło z Internetu - nie wprost, ale biorąc pod uwagę, że wielu z nas korzysta z Google jako jedynej, slusznej wyszukiwarki, to oznaczało koniec dla Ricka. Wiedząc jakimi reperkusjami to się kończy, szybko wyłączyłem komentarze niezarejestrowanych (i niestety nie wprost rozpocząłem zachęcanie do zapisywania się do usług Google). No cóż - takie życie. Mam nadzieję, że na jakiś czas mam spokój.