Java EE 6 i OSGi z FishCAT i "Pro Spring Dynamic Modules for OSGi Service Platforms"

Rozpoczął się FishCAT, czyli program testowania najnowszego wydania GlassFish v3 (b65), który ma ocenić gotowość produktu do produkcyjnych wdrożeń. Tym samym moja aktywność wokół Grails zostaje wzbogacona o doświadczenia z GlassFishem.

Z listu powitalnego do FishCAT - [FishCAT] Please start FishCAT testing on b65, Thanks ! - można przeczytać, że:

Here is FishCAT testing schedule. Bugs filed after the ending date may be differed to next release based on
the priority. Hope you will find some time in next to weeks to help us testing.

FishCAT Testing Schedule: 9/25/09 - 10/9/09 (2 weeks)
FishCAT doc review schedule: 9/25/09 - 10/9/09 (2 weeks)
FishCAT i18n/l10n testing: 9/25/09 - 10/21/09 (4 weeks)

czyli jedynie 2 tygodnie na testowanie produktu przed finalnym wydaniem. Zdaje się, że w tym czasie należy oczekiwać również wielu finalnych wydań specyfikacji wchodzących w skład Java EE 6. Proszę, proszę, to było w końcu rok temu, kiedy na rynku pojawiło się Java EE 5, a tu mamy nową wersję. Ta również ma być jeszcze ciekawsza niż poprzednie. I znowu wyścig serwerów aplikacyjnych o prym w realizacji Java EE 6 się zacznie.

Już od jakiegoś czasu przyglądałem się rozwojowi GF i co mnie najbardziej zachwyciło, to wsparcie dla OSGi. Oczywiście dodając do tego wsparcie Java EE 6 mamy pełen obraz, dlaczego zdecydowałem się na 2-tygodniowe turnee z GlassFishem w roli głównej. Sam udział w programie ma być pretekstem do powrotu do korzeni ze wspomnianymi technologiami, które zostały przesłonięte Grails.

Jako uzupełnienie mojego powrotu do Java EE/OSGi zabrałem się za lekturę "Pro Spring Dynamic Modules for OSGi Service Platform" z Apress. Jakkolwiek książce bliżej do rozwiązań opartych na Spring Framework, a więc bliżej jej do Grails niż GlassFish czy Java EE 6, to wszystkie technologie są tak ze sobą związane, że dotykając jednego trudno nie dotknąć innych.

Na pierwszy rzut oka, najbardziej egzotyczną technologią może wydawać się OSGi, ale właśnie z rozwiązaniami typu Spring-DM, czy GlassFish jego rola sprowadza się do ukrytego gracza, który wspiera infrastrukturę, na której nasze aplikacje są budowane (Spring-DM) i/lub uruchamiane (GlassFish). Właśnie podział na budowane-uruchamiane daje odpowiedź, dlaczego Spring-DM (strona OSGi) ma tak silny związek z GlassFish (strona Java EE 6). I coś co wydaje się być różne i odległe od siebie jest faktycznie nierozerwalne (albo przynajmniej takim powinno być).

Stworzenie aplikacji springowej może być rozbudowane o cechy OSGi z pomocą Spring-DM, a środowiskiem uruchomieniowym może być właśnie GlassFish (który niestety poza wykorzystaniem OSGi wewnętrznie nie daje możliwości skorzystania z niego w ramach wdrażanych aplikacji korporacyjnych). Spring Framework to wyłącznie szkielet aplikacyjny, którego główną cechą jest realizacja podejścia (wzorca?) Inversion of Control przez mechanizm Depenency Injection, który potrzebuje środowiska uruchomieniowego z jego usługami. Serwer aplikacyjny Java EE świetnie uzupełnia ofertę Spring Framework przez dostarczenie wszystkich obowiązkowych usług typu monitor transakcyjny, zarządca utrwalania danych JPA czy infrastruktura bezpieczeństwa.

Jeszcze podczas lektury "Grails in Action" doświadczyłem niesamowitego olśnienia odnośnie różnicy między Inversion of Control (IoC) a Dependency Injection (DI), co zwykłem traktować jako synonimy. Jakież było moje zdumienie, kiedy przeczytałem, że IoC to podejście (wzorzec?) tworzenia aplikacji, gdzie zarządzanie zależnościami oddelegowuje się do kontenera IoC, a DI to jedna z jego realizacji, która polega na przekazywaniu/wstrzykiwaniu owych zależności do komponentu zarządzanego (strona 396). Niestety, nie jestem w stanie wskazać innej realizacji IoC, ale na takie przedstawienie tematu mogę się zgodzić. Niewielka różnica, która często "fall through the cracks" (piękny idiom w j. angielskim, którego nie mogłem nie użyć w ramach pogłębiania mojej znajomości angielskiego).

Sama książka "Pro Spring Dynamic Modules for OSGi Service Platforms" rozpoczyna się, tak jak prawdopodobnie zaczyna się każda książka na ten temat - najpierw wprowadzenie do OSGi, później Spring Framework, dalej Spring Dynamic Modules, aż lądujemy z SpringSource dm Server w jednej dłoni, a jego rozwiązaniami wokół wersjonowania składowych aplikacji, dostępem do danych, aplikacjami webowymi i testowaniem w drugiej. Na razie mam za sobą pierwszy rozdział książki "Introducing OSGi" i mimo jedynie 42 stron na ten temat, warto było. Tak jak można było się tego spodziewać, było tworzenie pakunku OSGi, ale czego nie, to próba zarejestrowania jego funkcjonalności jako usługi (tak, było też wymienione SOA, ale tylko przez chwilę) i udostępnienie jej jako servlet za pomocą HTTP Service. Nie ma wiele rozpisywania się nt. OSGi, ale jest wystarczająco, aby wprowadzić w temat, a sam przykład jest zdecydowanie bardziej zaawansowany niż jego nazwa mogłaby wskazywać - HelloWorld. Jestem niezwykle zadowolony z tego, że zdecydowałem się na tę książkę. Leżała u mnie od lutego (!) Jest to książka drukowana, więc zainteresowani będą musieli odczekać jeszcze kilka tygodni, kiedy wróci do Biblioteki Warszawskiego JUGa.

Przede mną wprowadzenie do Spring Framework przez 60 stron. Już przez głowę przeszło mi, aby przerzucić te strony i zabrać się za kolejny rozdział 3. "Integrating Spring and OSGi". Nie będzie mi łatwo przebrnąć przez niego. Już tyle zostało powiedziane o Springu, a tu jeszcze 60 stron przede mną. Dobrze, że po nim znowu OSGi, a w odwodzie jest testowanie GlassFisha z NetBeans IDE 6.7.1/6.8 i nauka Java EE 6.