Tak mnie natchnęło podczas powrotu - CDI, Spring Framework, JBoss Seam i in.

W oczekiwaniu na samolot do Pragi, na lotnisku w Bratysławie, trafiłem do restauracji, która przypominała mi lata 80-te zeszłego wieku. Kiedy wreszcie podano mi kartę (ludzi było sporo i widać było, że kelnerzy biegają jak w ukropie) jeszcze bardziej byłem przerażony - strona graficzna karty przypominała mi moje nieśmiałe próby zabawy z grafiką, a nie mam złudzeń, że nie znam się na temacie. Mimo wszystko dałem się namówić samemu sobie, abym jednak spróbował. Zamówiłem danie, którego wygląd w karcie przypominał lata jak sama restauracja i aż do momentu podania wciąż walczyłem ze swoimi myślami, czy dobrze zrobiłem (co później okazało się bardzo pozytywnym zaskoczeniem!). Czekałem i patrzyłem przez okno na lotnisko, aż zacząłem zastanawiać się nad celem...specyfikacji JSR-299 Contexts and Dependency Injection (CDI) i, jakkolwiek wciąż przede mną część praktyczna, to wydaje mi się, że zrozumiałem jego istotę.

Jak sama nazwa specyfikacji CDI mówi (wręcz narzuca się ze swoim celem przez nią, ale najwyraźniej niezbyt nachalnie, bo dla mnie nie było to jasne, aż do tego momentu) sprawa dotyczy realizacji koncepcji zarządzania kontekstami (znamy przynajmniej 3, które istnieją w Java EE od wieków, ale i tych, które możnaby stworzyć, które pojawiły się w JSF2 conversation i potencjalnie dostępne z rozwiązaniami BPM - businessprocess) oraz obiektami, które podlegają mechanizmowi Dependency Injection (DI) w ramach kontekstu, który tym samym pełni rolę przestrzeni ich widoczności.

Jeśli miałbym szukać odpowiednika CDI w świecie poza JEE6, aby choć nieznacznie nawiązać kontakt myślowy z szerszą częścią czytelników, to byłby to na pewno Spring Framework (i nie mam na myśli jego rozszerzeń tylko sam "czysty" - bez dodatków - kontener DI). Bardziej idealnym odpowiednikiem byłby Guice, albo PicoContainer, albo jeszcze HiveMind, ale ich rozpoznanie nie należy do najszerszych, a to pewnie dlatego, że są bardzo specjalizowanymi rozwiązaniami, które nie doczekały się szerszego wsparcia gotowych rozwiązań "stosowych" (o nich za moment).

Skoro w temat tworzenia CDI zaangażowani byli autorzy JBoss Seam, to możnaby również mniemać, że i w nim coś już było, albo jest dopasowywane. I faktycznie tak jest. Pamiętam moment, kiedy dowiedziałem się o postrzeganiu JBoss Seam jako...kontenera DI, którego porównywano do...Spring Framework (!) Nie mogłem po prostu w to uwierzyć. Dla mnie Seam był i wciąż jest szkieletem webowym opartym na JEE, który był o tyle rewolucyjny, że połączył dwie technologie, które jakkolwiek pod parasolem JEE, to wciąż grały do innej bramki. Mowa o EJB3 i JSF 1.2. Dzięki Seam oba rozwiązania były jakby ukryte pod przykrywką warstwy komponentów i to właśnie stanowiło trzon, aby wprowadzić jako standard do JEE. Teraz to jasne (czasami warto znaleźć się w miejscu, w którym lepiej, aby nas nie było, np. kawiarnia na lotnisku, bo nieoczekiwane prowadzi do ciekawych chwil, których trudno by szukać w znanym i opanowanym mentalnie świecie).

Teraz wiem, dlaczego kiedy przeglądałem materiały do CDI, gdzieś na niskim pułapie wciąż przelatywał JSP i JSF2. Samo CDI to jedynie, albo aż, kontener DI, podobnie jak Spring Framework. Jednak do zbudowania aplikacji korporacyjnej potrzebujemy szkieletu webowego czy Web Services, czy innej obsługi protokołu do komunikacji z użytkownikiem końcowym. Tu jest miejsce dla JavaServer Faces 2.0 jako kompletnego szkieletu webowego, zintegrowanego z CDI. Kiedy dodamy do tego EJB3.1 mamy cały obraz najnowszego wydania Java Enterprise Edition 6.0. Teraz już jest łatwiej zrozumieć ich zmiany i powiązania między nimi.

Tak mnie natchęło, aby pochwalić się swoim znaleziskiem :-) Wracam do lektury specyfikacji. Jeszcze tylko kilka stron i teoretycznie będę "uzbrojony".