Usystematyzowanie nauki EJB 3.0 - Chapter 1: Introduction

Jak to w życiu bywa, zazwyczaj przemyślane podejścia mają szansę powodzenia. Czym więcej przemyślanych kroków, tym mniejsze ryzyko porażki. Postanowiłem sprawdzić to w praktyce w celu usystematyzowania mojej znajomości specyfikacji Enterprise JavaBeans 3.0 (EJB3 lub JSR 220) podchodząc do tematu w nowatorski dla mnie sposób. Mój plan polega na założeniu, że będę czytał specyfikację regularnie (najlepiej codziennie) po rozdziale, a wnioski z lektury spisywał i publikował w moim internetowym notatniku (blogu). W ten sposób upiekę dwie pieczenie na jednym ogniu (ang. to kill two birds with one stone), tzn. w usystematyzowany sposób poznam specyfikację i jednocześnie moje przemyślenia/relację wystawię na falę krytyki, która ostatecznie może jedynie udoskonalić moje zrozumienie tematu. Dodatkowo, wierzę, że w ten sposób wiele innych osób skorzysta na tym, szczególnie tych, którzy po kilku stronach specyfikacji, podobnie jak ja...zasypiają (co samo w sobie ma również swoje korzyści). Zakładam, że moja skondensowania wypowiedź będzie wystarczająco krótka, aby nie doprowadzić czytelnika do zaśnięcia. Nie byłoby to jednak zbyt interesujące, gdybym jedynie czytał (i zmuszał czytelnika do tego samego), więc planuję również testować nowozdobytą wiedzę w praktyce - na serwerze aplikacyjnym Glassfish, który jest referencyjną implementacją specyfikacji Java EE 5, której częścią jest EJB3. Można, więc spodziewać się przykładów - krótkich programów, których jedynym celem będzie rozpoznanie technologii, a nie rozwiązywanie problemów biznesowych (innymi słowy: będą to często programy bez większego sensu poza samym wkładem naukowym). Nie tracąc czasu na zbędne elaboraty przystępuję do realizacji mojego planu. Rozpoczynam lekturę od dokumentu EJB 3.0 Simplified API.

Dokument EJB 3.0 Simplified API składa się z 12 rozdziałów, przy czym 12. rozdział jest dodatkiem o historii dokumentu. Znajomość zmian jakie następowały w dokumencie odzwierciedla bolączki z jakimi przyszło zmagać się twórcom specyfikacji, więc jego znajomość jest równie cenna, jak pozostałych. Natomiast, 11. rozdział jest wyłącznie zestawieniem odnośników do dalszych lektur, więc ten nam odpada. Pozostaje 11 rozdziałów do przeczytania.

Cały dokument to 60 stron pisany w dość przystępnej formie. Mam nadzieję, że moje relacje nie sprowadzą się do kopiowania części dokumentu, co jest nielegalne bez zgody autora (i jeśli zdarzy mi się to popełnić, zaraz proszę o przesłanie informacji).

Rozpoczynam od rozdziału Chapter 1: Introduction.

Celem EJB 3.0 jest:

• uproszczenie tworzenia komponentów EJB, m.in. poprzez uproszczenie EJB API, co zwiększa atrakcyjność specyfikacji
  
• zgodność z EJB 2.1, co umożliwia migrację do nowego środowiska bez konieczności przepisywania aplikacji
• możliwość jednoczesnego korzystania z EJB 2.1 i EJB 3.0
• wykorzystanie dobrodziejstw nowości Java SE 5 - annotacji, co pozwala na określanie znaczenia klasy/interfejsu w aplikacji bez konieczności utrzymywania zewnętrznych plików, których często trudno było utrzymać aktualne (bez stosowania rozwiązań pomocniczych jak XDoclet - kolejny otwarty projekt, który miał wpływ na specyfikację EJB3)
• zmniejszenie ilości klas/interfejsów do niezbędnego minimum, czyli powrót do korzeni języka Java, do specyfikacji JavaBeans, która była dostępna od jej pierwszych dni (ech, rzeczy proste zwykle pozostają niezauważane)
• usunięcie konieczności rozszerzania klas czy implementacji interfejsów, co przywiązywało nasze komponenty EJB 3.0 ze środowiskiem serwera aplikacyjego. Obecnie zwykła klasa realizująca specyfikację JavaBeans - POJO (ang. plain old java object) gra główne skrzypce.
• uproszczenie konstruowania powiązań między częściami aplikacji za pomocą annotacji, bez konieczności definiowania ich w plikach pomocniczych, np. ejb-jar.xml, web.xml, czy innych.
• wprowadzenie ustawień domyślnych, które można nadpisywać annotacjami, czy (opcjonalnie) deklaracjami w pliku ejb-jar.xml. W poprzedniej wersji specyfikacji wiele domyślnych ustawień było specyficznych dla serwera aplikacyjnego, co powodowało, że wykorzystana wartość domyślna mogła przyjmować różne wartości dla różnych serwerów.
• stworzenie JPA (Java Persistence API) dzięki, któremu zdefiniowano ujednoliconą warstwę zarządzania obiektami trwałymi, gdzie dostarcza się sterowników JPA (np. Hibernate) realizujących kontrakt (podobnie jak sterowniki JDBC w stosunku do JDBC).
• uproszczenie mechanizmu notyfikacji o sytuacjach wyjątkowych w aplikacji
  

Jednym słowem twórcy specyfikacji nauczyli się oddychać tym samym powietrzem, co projektanci i programiści ze świata rozwiązań otwartych, np. Spring Framework, czy Hibernate i zapożyczyli wiele z rozwiązań. Wpływy tych projektów widać, aż nadto (i stąd moje przekonanie, że Spring Framework+Hibernate nie wprowadza do naszych rozwiązań przemysłowych - tych opartych o standard Java EE 5 - niczego, czego nie byłoby już dostępnego w serwerze aplikacji). Nadeszła ponownie era Java EE.