Najlepsze techniki pracy z Jarą EE!
Java' EE
Zaawansowane wzorce projektowe
Murat Yener, Alex Theedom
HelionVT
Spis treści
O autorach........................................................................................................11 O korektorze m erytorycznym .........................................................................13 Podziękow ania................................................................................................ 15 Przedm ow a......................................................................................................17 Wprowadzenie................................................................................................. 19
Rozdział 1.
Krótki przegląd wzorców projektowych........................................................ 27 Czym jest wzorzec projektowy ......................................................................................... 28 Jak odkryto wzorce i do czego są potrzebne .............................................................29 Wzorce w realnym św iecie.......................................................................................... 30 Podstawy wzorców p rojektow ych.................................................................................... 31 Wzorce w rozwiązaniach dla biznesu .............................................................................. 31 Od Javy do Javy dla b iz n e s u ........................................................................................ 31 Pojawienie się wzorców Javy dla przedsiębiorstw ....................................................32 Wzorce projektowe a wzorce biznesow e...................................................................33 Stare dobre wzorce projektowe spotykają Javę E E ...................................................33 Kiedy wzorce stają się antyw zorcam i......................................................................... 35 P odsum ow anie.....................................................................................................................35
Rozdział 2.
Podstawy Javy E E ............................................................................................37 Architektura wielowarstwowa .......................................................................................... 38 W arstwa kliencka................................................................................................................ 39 W arstwa logiki biznesowej ................................................................................................ 40 K om ponent sieciow y.................................................................................................... 40 W arstwa EIS ........................................................................................................................ 40 Serwery Java E E ................................................................................................................... 41 Profil sieciowy Javy E E ....................................................................................................... 42 Podstawowe zasady Javy E E .............................................................................................. 42
6 I JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
Konwencja przed k onfiguracją......................................................................................... 43 CDI ........................................................................................................................................43 In tercep to ry ..........................................................................................................................44 P odsum ow anie.................................................................................................................... 45 Ć w iczenia..............................................................................................................................45
Rozdział 3.
Wzorzec Fa sa d a ...............................................................................................49 Czym jest F asad a..................................................................................................................50 Diagram klas wzorca F asad y....................................................................................... 51 Implementacja wzorca Fasada w zwykłym kodzie źródłow ym ................................... 52 Implementacja wzorca Fasada w Javie E E .......................................................................53 Fasada z ziarnami bezstanow ym i............................................................................... 53 Fasada ze stanowym ziarnem .....................................................................................55 Gdzie i kiedy używać wzorca Fasada ............................................................................... 55 P odsum ow anie.....................................................................................................................56 Ć w iczenia..............................................................................................................................56
Rozdział 4.
Wzorzec Singleton .......................................................................................... 57 Czym jest S in g leto n .............................................................................................................58 Diagram klas wzorca Singleton .................................................................................. 59 Implementacja wzorca Singleton w zwykłym k o d zie ..............................................59 Implementacja wzorca Singleton w Javie E E ..................................................................63 Ziarna singletonow e..................................................................................................... 63 Wykorzystywanie singletonów przy u ru c h am ian iu ................................................64 Określanie kolejności urucham iania .........................................................................65 W spółbieżność.............................................................................................................. 67 Gdzie i kiedy używać wzorca S ingleton...........................................................................69 P odsum ow anie.................................................................................................................... 69 Ć w iczenia............................................................................................................................. 70
Rozdział 5.
Wstrzykiwanie zależności i C D I...................................................................... 71 Na czym polega wstrzykiwanie zależności......................................................................72 Implementacja wstrzykiwania zależności w zwykłym k o d z ie ..................................... 72 Implementacja wstrzykiwania zależności w Javie E E ....................................................75 Adnotacja @Named ..................................................................................................... 76 Wstrzykiwanie zależności i kontekst (C D I)..............................................................77 CDI a E JB ........................................................................................................................78 Ziarna CDI .....................................................................................................................78 Adnotacja @Inject ........................................................................................................ 79 Konteksty i za k re s......................................................................................................... 79 Nazewnictwo i E L ......................................................................................................... 80 Ziarna CDI jako wsparcie dla JSF .............................................................................. 80 Kwalifikatory..................................................................................................................81 A lternatyw y....................................................................................................................81
I7
Stereotypy ................................................................................ Inne wzorce związane z C D I ................................................ Podsumowanie .............................................................................. Ć w iczenia.......................................................................................
...82 ...82 ...83 ...83
Wzorzec Fabryka .............................................................
. 85
Czym jest Fabryka ........................................................................ M etoda F ab ry czn a....................................................................... Implementacja M etody Fabrycznej w zwykłym kodzie ... Fabryka Abstrakcyjna ................................................................. Implementacja Fabryki Abstrakcyjnej w zwykłym kodzie Implementacja wzorca Fabryka w Javie EE ............................. Okiełznać moc kontenera C D I ............................................ Gdzie i kiedy używać wzorców fabrycznych............................ Podsumowanie ............................................................................. Ćwiczenia .......................................................................................
...86 ..86 ..88 ..89 ..90 ..91 ..97 100 101 101
Wzorzec Dekorator..........................................................
103
Czym jest wzorzec Dekorator .................................................... Diagram klas wzorca Dekorator .......................................... Implementacja wzorca Dekorator w zwykłym kodzie ........... Implementacja wzorca Dekorator w Javie EE ......................... Dekoratory bez konfiguracji X M L ....................................... Gdzie i kiedy używać wzorca Dekorator .................................. P odsum ow anie.............................................................................. Ć w iczenia.......................................................................................
104 105 106 109 113 114 115 115
Programowanie aspektowe (interceptory)....................
117
Co to jest programowanie aspektow e........................................ Implementacja AOP w zwykłym kodzie ................................... Aspekty w Javie EE i interceptory .............................................. Cykl życia interceptora ......................................................... Interceptory na poziomie domyślnym ............................... Kolejność interceptorów ....................................................... Interceptory CDI ................................................................... Gdzie i kiedy używać interceptorów ......................................... Podsumowanie .............................................................................
118 120 122 125 125 126 128 130 131
Asynchroniczność ...........................................................
133
Co to jest programowanie asynchroniczne .............................. W zorzec A synchroniczność.................................................. Implementacja asynchroniczności w zwykłym ko d zie........... Programowanie asynchroniczne w Javie E E ............................ Asynchroniczne ziarna ......................................................... Asynchroniczne serw lety....................................................... Gdzie i kiedy stosować programowanie asynchroniczne ....... P odsum ow anie.............................................................................. Ć w iczenia.......................................................................................
134 134 136 138 138 140 143 144 145
8 I JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
Rozdział 10. Usługa odmierzania cza su ............................................................................ 147 Czym jest usługa odmierzania czasu .............................................................................. 148 Implementacja czasomierza w Javie E E ......................................................................... 150 Czasomierze autom atyczne....................................................................................... 150 Czasomierze prog ram o w e......................................................................................... 151 Wyrażenia czasowe .....................................................................................................153 T ransakcje.....................................................................................................................156 P odsum ow anie...................................................................................................................156 Ć w iczenia............................................................................................................................157
Rozdział 11. Wzorzec Obserwator.................................................................................... 159 Czym jest O b serw ato r.......................................................................................................160 Opis ...............................................................................................................................160 Diagram klas wzorca Obserwator ............................................................................ 162 Implementacja wzorca Obserwator w zwykłym k o d z ie ..............................................162 Implementacja wzorca Obserwator w Javie E E ............................................................164 Gdzie i kiedy używać wzorca O bserw ator.....................................................................169 P odsum ow anie.................................................................................................................. 170 Ć w iczenia............................................................................................................................170
Rozdział 12. Wzorzec Dostęp do Danych.......................................................................... 171 Czym jest wzorzec Dostęp do D an y ch........................................................................... 172 Diagram klas Dostępu do D a n y c h ........................................................................... 172 Ogólne informacje o wzorcu Dostęp do D a n y c h .........................................................173 W zorzec Obiekt Transferu D a n y c h ......................................................................... 173 API JPA i O R M ............................................................................................................174 Implementacja wzorca Dostęp do Danych w Javie E E ................................................174 Implementacja DAO bezpieczna pod względem ty p ó w .......................................179 Gdzie i kiedy używać wzorca Dostęp do D an y ch ......................................................... 180 P odsum ow anie...................................................................................................................180 Ć w iczenia............................................................................................................................180
Rozdział 13. REST-owe usługi sieciowe ............................................................................ 181 Co to jest REST ..................................................................................................................182 Sześć warunków R E S T ......................................................................................................183 K lient-serw er................................................................................................................183 Jednolity interfejs.........................................................................................................184 Bezstanowość ...............................................................................................................184 Możliwość zapisywania danych w buforze ............................................................. 184 System w arstw ow y.......................................................................................................184 Kod na żąd an ie.............................................................................................................184 Model dojrzałości Richardsona ...................................................................................... 185 Poziom 0. — zwykły X M L ......................................................................................... 185 Poziom 1. — z a so b y ................................................................................................... 185 Poziom 2. — czasowniki HTTP ............................................................................... 185 Poziom 3. — kontrolki h ip erm ed ialne....................................................................185
Spis treści I 9
Projektowanie REST-owego interfejsu A P I .................................................................. 185 Nazewnictwo zasobów ............................................................................................... 186 Rzeczowniki, a nie czasow niki.................................................................................. 186 Znaczenie n a z w ........................................................................................................... 187 Liczba m n o g a .............................................................................................................. 187 M etody H T T P ............................................................................................................. 187 REST w a k c ji.......................................................................................................................188 Rzeczownik u se rs.........................................................................................................188 Rzeczowniki topics i p o s ts ......................................................................................... 189 Implementacja REST w Javie EE .................................................................................... 191 H A T E O A S..........................................................................................................................194 Gdzie i kiedy używać R E S T ............................................................................................. 196 P odsum ow anie...................................................................................................................197 Ć w iczenia............................................................................................................................197
Rozdział 14. Wzorzec Model - Widok - Kontroler............................................................199 Czym jest wzorzec MVC ................................................................................................. 200 Typy wzorca MVC ..................................................................................................... 201 Implementacja wzorca MVC w zwykłym k o d z ie .........................................................202 Implementacja wzorca MVC w Javie E E .......................................................................206 Serwlet FacesServlet.......................................................................................................... 206 Implementacja wzorca MVC przy użyciu serwletu FacesServlet.............................. 206 Gdzie i kiedy używać wzorca MVC ................................................................................ 208 Podsumowanie .................................................................................................................. 209 Ćwiczenia ............................................................................................................................209
Rozdział 15. Inne wzorce projektowe w Javie E E ..............................................................211 Co to są gniazda sieciowe ................................................................................................ 212 Co to jest warstwa pośrednia do przekazywania w iadom ości................................... 214 Co to jest architektura mikrousługowa .........................................................................215 Architektura m ono lity czn a....................................................................................... 215 Skalowalność ............................................................................................................... 217 Dekompozycja na usługi ........................................................................................... 218 Zalety architektury mikrousługowej ........................................................................218 Nie m a nic za darmo .................................................................................................. 219 W nioski ........................................................................................................................ 220 Kilka antywzorców na zakończenie ...............................................................................220 Uberklasa ..................................................................................................................... 220 A rchitektura L azani.................................................................................................... 221 Pan K olu m b ................................................................................................................. 221 Korzyści z przyjaźni ................................................................................................... 221 Supernowoczesność ................................................................................................... 222 Szwajcarski scyzoryk .................................................................................................. 222
10 I JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
Rozdział 16. Wzorce projektowe — dobre, złe i brzydkie................................................ 225 Dobre — wzorce sukcesu................................................................................................. 225 Złe — nadużywanie i błędne stosowanie w zorców ..................................................... 227 Brzydkie ............................................................................................................................. 228 P odsum ow anie.................................................................................................................. 230
Sko ro w id z..................................................................................................... 231
O autorach
MURAT YENER jest maniakiem program owania i działaczem ruchu open source. Pracuje w Intel New Devices Group na stanowisku programisty Androida. Posiada bogate doświadczenie w zakresie program ow ania w języku Java, sieciowych systemów szkieletowych, technologii Java EE oraz aplikacji OSGi. Ponadto prowadzi różne kursy i zajmuje się doradztwem. Yener jest jednym z program istów środowiska Eclipse i należy do grona twórców projektu Eclipse Libra. Aktualnie pochłania go budowanie rodzim ych i hybrydowych aplikacji mobilnych przy użyciu technologii HTML5 i mGWT. Od 2009 r. M urat Yener jest liderem grupy użytkowników w GDG Istanbul. Organizuje różne imprezy i sam również bierze w nich udział. Często też m ożna go spotkać na konferencjach JavaOne, EclipseCon i Devoxx. LinkedIn — www.linkedin.com/in/muratyener. T w itter — @yenerm. Blog — www.devchronicles.com.
ALEX THEEDOM jest starszym programistą Javy w Indigo Code Collective (indigocodecollective.com — część grupy E-scape), gdzie był głównym architektem i program istą opartej na mikrousługach platformy loteryjnej z natychmiastowymi wynikami. Wcześniej tworzył oprogramowanie bankomatów dla międzynarodowego hiszpańskiego banku i program do analizy jakości kodu dla konsultantów programistycznych. Theedom m a doświadczenie w pisaniu aplikacji sieciowych w Javie dla różnych branż, takich jak: finanse, e-learning, loterie i wytwarzanie oprogramowania. Dzięki swojemu entuzjastycznemu podejściu do program owania pracował w wielu miejscach na świecie. Prowadzi blog pod adresem: alextheedom.com i często pomaga innym program istom, udzielając się na forach internetowych. L inkedIn — www.linkedin.com/in/alextheedom. T w itter — @alextheedom. Blog — www.alextheedom.com.
12 | JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
O korektorze merytorycznym
M OHAM ED SANAULLA jest program istą z ponadpięcioletnim doświadczeniem w zawodzie. Aktualnie pracuje w największej w Indiach firmie zajmującej się handlem elektronicznym oraz pełni funkcję m oderatora na forach JavaRanch. Po pracy opiekuje się śliczną małą córeczką. Pisze o swoich eksperymentach i przemyśleniach dotyczących programowania na blogu znajdującym się pod adresem: http://blog.sanaulla.info.
Zespół wydania oryginalnego ASSOCIATE PUBLISHER Jim Minatel PROJECT EDITOR Adaobi Obi Tulton TECHNICAL EDITOR M ohamed Sanaulla PRODUCTION MANAGER Kathleen W isor COPY EDITOR Karen A. Gill MANAGER OF CONTENT DEVELOPMENT AND ASSEMBLY Mary Beth Wakefi eld
PROFESSIONAL TECHNOLOGY AND STRATEGY DIRECTOR Barry Pruett BUSINESS MANAGER Amy Knies PROJECT COORDINATOR, COVER Patrick Redmond PROOFREADER Nancy Carrasco INDEXER John Sleeva COVER DESIGNER Wiley
MARKETING DIRECTOR David Mayhew
COVER IMAGE © iStock.com/pavlen
MARKETING MANAGER Carrie Sherrill
BACKGROUND © PhotoAlto Images/Fotosearch
Podziękowania
M ÓJ W SPÓŁAUTOR Alex zawsze powtarzał, że powinniśm y napisać taką książkę, jaką sami chcielibyśmy kupić i przeczytać. Dlatego dziękuję m u za cierpliwość, ciężką pracę i wielką wiedzę. Gdyby nie on, ta książka nie byłaby nawet w połowie tak dobra, jak jest. Dziękuję Mary James, naszej poprzedniej redaktorce inicjującej, która skontaktowała się ze m ną w sprawie napisania książki o Springu, ale wysłuchała moich pomysłów, których efektem jest niniejsza publikacja. Bez jej wsparcia i porad ta książka by nie powstała. Brak m i słów, aby odpowiednio podziękować Adaobi Obi Tulton, która panowała nad wszystkimi szczegółami i chroniła nas przed stresem związanym ze zbliżającymi się terminami. I oczywiście dziękuję wszystkim z wydawnictwa Wrox/W iley, którzy przyczynili się do powstania tej książki. Dziękuję też Rezie Rahmanowi za otuchę. Chcę również podziękować trzem bardzo ważnym dla mnie osobom, które ukształtowały moją karierę programistyczną. Po pierwsze, dziękuję m ojem u tacie Mustafie Yenerowi za kupienie mi pierwszego kom putera C64, gdy byłem mały i prosiłem go o miniaturowy tor wyścigowy. Na tym komputerze napisałem swoje pierwsze programy. Po drugie, dziękuję m ojem u prom otorow i profesorowi Mahirowi Vardarowi, który pokierował m ną na początku mojej kariery. I w końcu dziękuję m ojem u mentorowi i przyjacielowi (a także byłemu szefowi) Naciemu Daiowi, który nauczył mnie prawie wszystkiego, co wiem o profesjonalnym programowaniu. Murat
JESTEŚMY BARDZO DUM NI z tej naszej pierwszej książki i m am y nadzieję, że nauczysz się z niej przynajmniej tyle, co m y podczas jej pisania. Pisaliśmy ją tak, abyśmy chcieli ją sami kupić, gdybyśmy nie byli jej autorami. Udało nam się to. Ale oczywiście nad książką pracowało z poświęceniem, cierpliwością i zrozumieniem wiele innych osób, które miały pośredni lub bezpośredni wkład w to dzieło. Dziękujemy za pomoc doświadczonemu i oddanemu zespołowi z wydawnictwa Wiley Publishing. Byli z nami na dobre i na złe, nigdy nie tracąc
16
| JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
pewności, że wszystko się uda. Szczególnie dziękujemy Mary James, naszej redaktorce inicjującej, której wsparcie przyczyniło się do powstania tej książki. Dziękujemy też Adaobi Obi Tulton, która cierpliwie i umiejętnie zachęcała nas do pracy, a dzięki swojej drobiazgowości uchroniła nas przed wieloma wpadkami. Dziękuję m ojem u współautorowi Muratowi Yenerowi za inspirację i poczucie hum oru, które wyróżnia tę książkę na tle innych. I w końcu dziękuję też mojej żonie Marii Eugenii Gar d i Gar d i za wsparcie i zrozumienie okazane mi podczas pisania. Dziękuję. Alex
Przedmowa
Ignoranci zadają pytania, na które uczeni odpowiedzieli ju ż tysiące lat temu — Jo h a n n W o
lfg a n g v o n
Go e th e
Wzorce projektowe są wehikułem czasu łączącym przeszłość z przyszłością. Stanowią fundam ent reprezentujący znane rozwiązania typowych problemów, które utalentowani inżynierowie kiedyś dodali do zbiorowej skarbnicy wiedzy. Wzorce projektowe czy szablony w pewnej formie występują w każdej dziedzinie inżynierii, także w program owaniu. W istocie wzorce te są najważniejszym ogniwem łączącym naszą profesję z inżynierią, a nie z bardziej organicznym i mniej skodyfikowanym światem artystycznym i rzemieślniczym. Sztuka i nauka wzorców projektowych zostały wprowadzone do świata inżynierii oprogramowania — a konkretnie do Javy dla przedsiębiorstw — w nowatorskiej książce Bandy Czworga. Od tamtej pory korzystamy z nich przy programowaniu w J2EE, w Springu, a teraz też w nowoczesnej i odchudzonej Javie EE. Są ku temu istotne powody. Programiści serwerowi Javy często piszą bardzo ważne dla powodzenia różnych projektów aplikacje, które muszą wytrzymać próbę czasu, a więc powinni jak najwięcej korzystać z wypróbowanych wzorców. Nie każdy nadaje się do napisania książki o wzorcach projektowych, nie mówiąc już o tym, jak je praktycznie wykorzystać w aplikacjach Java EE. Do tego potrzeba nie tylko wiedzy o interfejsach API i samych wzorcach, ale wymagane jest również dogłębne zrozumienie tematu, które m ożna zyskać wyłącznie w miarę nabywania doświadczenia, jak również wrodzona umiejętność prostego objaśniania skomplikowanych zagadnień. Cieszę się, że M urat i Alex postanowili zmierzyć się z tym wyzwaniem. Książka ta znakomicie wypełnia pewną ważną lukę. Jej dodatkowymi zaletami są aktualność książki i znajdujący się w niej opis Javy EE 7, a nie 6 czy 5, bo przecież wiele wzorców, jak choćby: Singleton, Fabryka, Model - W idok - Kontroler, Dekorator czy Obserwator, jest już wbudowanych bezpośrednio w platformę Java EE. Na tej podstawie można z powodzeniem stosować inne wzorce, np.: Fasada, Obiekt Dostępu do Danych i Obiekt Transferu Danych. M urat i Alex opisują każdy wzorzec, wyjaśniają jego praktyczne zastosowanie oraz wskazują jego miejsce w Javie EE. Czuję się zaszczycony tym, że mogłem napisać krótki wstęp do tej bardzo ważnej książki, i mam nadzieję, że znajdzie się ona na półce każdego dobrego programisty Javy EE. Liczę, że spodoba Ci się ta książka oraz że dzięki niej zaczniesz pisać jeszcze lepsze i bardziej satysfakcjonujące biznesowe aplikacje w Javie. M. R e z a R a h m a n ewangelista Javy EE i GlassFisha Oracle Corporation
18 | JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
Wprowadzenie
W KSIĄŻCE TEJ PRZEDSTAW IONO KLASYCZNE W ZORCE PROJEKTOW E po raz pierwszy opisane w słynnej publikacji Bandy Czworga1, po dostosowaniu ich do specyfiki technologii Java EE 6 i 7. W każdym rozdziale znajduje się opis tradycyjnych implementacji jednego ze wzorców oraz sposobów zaimplementowania przy użyciu Javy EE. Obie implementacje (tradycyjną i w Javie EE) przedstawiamy w całości oraz okraszamy je prawdziwymi historiam i użycia lub nadużycia danego wzorca. Wyjaśniamy, jakie są zalety i wady każdego ze wzorców, i analizujemy sposoby ich użycia. N a końcu większości rozdziałów znajdują się ćwiczenia, których wykonanie ułatwia dogłębne zrozumienie tematu.
Adresaci książki Książka ta jest przeznaczona dla wszystkich program istów niezależnie od poziomu doświadczenia. Każdy wzorzec jest opisany od A do Z, czyli od tego, jak nazywają go w innych książkach, przez im plem entację w podstawowej Javie po implementację w Javie EE i rzeczywiste przykłady tego, kiedy i jak używać danego wzorca. Ponadto przedstawiono prawdziwe historie obrazujące właściwe i niewłaściwe przykłady użycia wzorców. Znajomość podstaw wzorców projektowych i Javy EE ułatwia zrozumienie m ateriału z książki. Czytelnicy znający już wzorce projektowe i umiejący je implementować w podstawowej Javie mogą od razu przejść do implementacji w Javie EE. W arto uprzednio odświeżyć sobie pamięć na temat wzorców projektowych.
1 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010.
20
I JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
Treść książki W książce opisano wszystkie klasyczne wzorce projektowe dostępne w standardowej implementacji Javy EE oraz parę nowych. Opisy sięgają od Javy EE 5 do najnowszej obecnie wersji Javy EE 7. Mamy nadzieję, że ta książka pozostanie na Twojej półce niezbędnych podręczników przez długi czas.
Struktura książki Każdy rozdział jest poświęcony jednem u wzorcowi projektowemu. Jeśli jest to wzorzec klasyczny, to po teoretycznym objaśnieniu wzorca przedstawiamy jego implementację w podstawowej Javie. W każdym rozdziale opisujemy też prawdziwe historie prawidłowego lub nieprawidłowego sposobu użycia danego wzorca. Potem przedstawiamy implementację w Javie EE, przykład i objaśnienie. Wszystkie przykłady kodu m ożna uruchomić. Na końcu rozdziałów znajdziesz porady na temat tego, kiedy i jak efektywnie wykorzystywać określony wzorzec.
Co jest potrzebne Do uruchomienia przykładów kodu wystarczy norm alny w miarę nowoczesny komputer z systemem operacyjnym, w którym zainstalowana jest maszyna wirtualna Javy. Pisanie kodu źródłowego jest łatwiejsze w zintegrowanym środowisku programistycznym, ale nie narzucamy żadnego konkretnego. Nasze przykłady można uruchomić w każdym popularnym środowisku, np.: Eclipse, NetBeans i IntelliJ. Do kompilowania i uruchamiania przykładów kodu potrzebny jest pakiet narzędzi programistycznych Java Development Kit (JDK) dla Javy EE 7, chociaż niektóre przykłady można też uruchomić przy użyciu starszych wersji tego pakietu. Do uruchom ienia przykładów można wykorzystać każdy serwer aplikacji obsługujący Javę EE 7. My użyliśmy do tego celu GlassFisha będącego referencyjną implementacją serwera oraz TomEE, który jest przystosowaną do Javy EE wersją popularnego Tomcata. Możesz używać dowolnego serwera, ale GlassFish jest implementacją odniesienia, więc warto poważnie wziąć go pod uwagę. Podsumowując — do uruchom ienia przykładowych program ów z tej książki potrzebne są następujące narzędzia: ^
system operacyjny z JDK dla Javy EE 7, np.: Linux, Mac OS X albo Windows;
>
JDK dla Javy EE 7;
^
wybrane środowisko programistyczne, np. Eclipse dla programistów Javy EE, NetBeans lub IntelliJ;
^
serwer aplikacji obsługujący Javę EE 7, np. GlassFish albo TomEE.
Kod źródłowy przykładów można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip.
Dlaczego powstała ta książka?
| 21
Dlaczego powstała ta książka? W listopadzie 2011 r., po dyskusji na tem at tego, czy w planowanym projekcie wykorzystać Javę EE, czy system Spring, wróciłem do swojego biurka i napisałem na blogu artykuł pt. Java EE 6 i Ewoki2, który bardzo szybko zdobył dużą popularność. Opowiadanie oparłem na serialu telewizyjnym Jak poznałem waszą matkę, w którym Barney, serialowy podrywacz, przedstawił teorię o Ewokach, czyli przypominających pluszowe misie stworach pojawiających się w szóstej części Gwiezdnych wojen. Fani mieli mieszane uczucia co do tych stworzeń. W edług Barneya osoby urodzone przed 25 maja 1983 r., czyli datą prem iery Powrotu Jedi, uważają Ewoki za dziecinne stwory i nie przepadają za nimi. N atomiast wszyscy, którzy urodzili się po tej dacie, kojarzą je z pluszowymi misiami i je lubią. W racając do mojego opowiadania: dyskusja z klientem o tym, czy lepiej użyć Javy EE, czy Springa, przypom niała mi właśnie teorię Ewoków. Osoby, które z racji wieku używały kiedyś J2EE 1.4 (EJB 1.0, 2.0, 2.1) w projektach korporacyjnych, korzystały z powolnego bezproduktywnego środowiska programistycznego zawierającego błędy powodujące m arnowanie RAM-u i z uruchamiającego się kilka m inut serwera sieciowego. Architektura ta była przypadkiem przerostu formy nad treścią i ostatecznie upadła, a jej miejsce zajął Spring. Tamci użytkownicy nienawidzą Javy EE bez względu na wersję. Przez to wersja Javy EE 5 nie została doceniona i na nikim nie zrobiła wrażenia. Java EE nigdy nie będzie taka jak J2EE. Teraz jest to otw arta technologia skupiająca dużą społeczność i zmieniająca się pod wpływem dobrych pomysłów czerpanych z takich systemów, jak Spring i H ibernate. Pierwsza wielka zm iana dotyczyła architektury i stylu pisania kodu. W Enterprise JavaBeans (EJB) zastosowano m odel lekkich zwykłych obiektów Javy (POJO), prawie bezwartościowe ziarna encyjne zastąpiono interfejsem JPA (ang. Java Persistence API), usługi REST-owe i sieciowe uczyniono standardową i integralną częścią systemu wykonawczego, a adnotacje zastąpiły konfigurację XML. Mimo to niektórzy twierdzą, że Java EE 5 nie była gotowa na wielkie zmiany, ponieważ nie została tak rozwinięta jak Spring, a środowisko programistyczne wciąż działało zbyt ociężale. Wykorzystanie Springa na serwerze Tomcat zamiast ziaren EJB i Javy EE 5 na serwerze aplikacji pozwalało znacznie zwiększyć produktywność, mimo to Java EE 5 była ważnym krokiem w kierunku odrodzenia platform y Enterprise Java. Kolejnymi krokam i były Java EE 6 i 7, w których zastosowano te same zasady i pomysły co w Javie EE 5. Java EE to aktualnie doskonały wybór, ale zgodnie z teorią Ewoków dyskusja wciąż trwa. Pewnego gorącego sierpniowego dnia zadzwonił do mnie ktoś z wydawnictwa W rox/W iley z pytaniem, czy byłbym zainteresowany napisaniem książki o Springu. Miałem doświadczenie i dobrze wiedziałem, jak programować przy użyciu tej technologii, ale na ten tem at było już wiele książek, przez co wydawało mi się, że nie m a sensu pisać kolejnej. Poza tym od pojawienia się Javy EE 6 wykorzystywałem tę technologię niezwykle często. Biorąc pod uwagę dyskusje na tem at wyższości Springa nad Javą EE i odwrotnie, moje wpisy na blogu oraz Ewoki, bardziej interesowało mnie napisanie książki o Javie EE. Podobnie jak w przypadku Springa w księgarniach można było już znaleźć wiele świetnych książek o Javie EE, które bardzo m i się podobały. Ale zawsze miałem wrażenie, że pewne cechy Javy EE były niedoceniane. Java EE m a wbudowane świetne implementacje wzorców projektowych, w których w bardzo prosty sposób wykorzystano adnotacje.
2 Java EE 6 and the Ewoks, http://w w w .devchronicles.com /2011/11/javaee6-and-ew oks.htm l.
22
| JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
Klasyczne wzorce projektowe opisane w książce Bandy Czworga były powszechnie stosowane prawie we wszystkich językach program owania, w systemach szkieletowych i na platformach. J2EE ani Java EE nie były pod tym względem wyjątkami. W istocie to programiści Javy EE wykonali śmiały krok polegający na dostarczeniu domyślnych implementacji wielu z tych wzorców, a mimo to wielu nawet najbardziej doświadczonych program istów nie doceniało tych udogodnień. N a blogu pisałem o tych wzorcach już prawie od roku, więc postanowiłem złożyć kontrofertę dotyczącą napisania książki o klasycznych wzorcach projektowych w Javie EE. Skoro czytasz tę książkę, to pewnie domyślasz się, że wydawnictwo przystało na moją propozycję. Książka ta wypełnia lukę dotyczącą braku opisu klasycznych wzorców projektowych z książki Bandy Czworga na platformie Java EE oraz zawiera opis paru nowych wzorców. Dzięki tem u nasza książka nie stała się kolejną pozycją o Javie EE, lecz katalogiem wzorców projektowych w Javie EE. Aby poszerzyć wiedzę i zdobyć więcej doświadczenia w pracy z platformą, w którą mocno wierzyłem, zacząłem pisać o niej na blogu i udzielać się na poświęconych jej konferencjach. Krótko mówiąc: dla mnie najlepsze w pisaniu tej książki było to, że mogłem pisać o czymś, co mnie fascynuje. Choć na blogu miałem prostsze przykłady, czasami wykorzystywałem go jako podręcznik, a więc napisanie książki zawierającej lepiej uporządkowany materiał było dla mnie nie lada okazją. Każdy napisany przez nas rozdział m a ten sam cel: aby zawarta w nim treść była na tyle dobra, że sami chcielibyśmy ją przeczytać. W efekcie powstała książka, którą każdy z nas trzym a pod ręką jako łatwo dostępne źródło informacji. Mamy nadzieję, że jej lektura sprawi Ci tyle satysfakcji, co nam jej napisanie.
Konwencje typograficzne Aby pom óc Ci jak najwięcej wynieść z lektury tej książki i nie zgubić wątku podczas czytania, zastosowaliśmy kilka konwencji typograficznych. UWAGA Tak oznaczamy różne uwagi, wskazówki, podpowiedzi, sztuczki i treści niemające bezpośredniego związku z otaczającym tekstem. Style stosowane w tekście: ^
W prowadzane nowe term iny i ważne słowa pogrubiam y.
^
Skróty klawiszowe, nazwy plików i adresy URL oznaczamy tak: Ctrl+A.
^
Fragmenty kodu w tekście oznaczamy następująco: p e r s is te n c e .p r o p e r tie s .
^
Bloki kodu źródłowego zapisujemy na dwa sposoby:
W większości przykładów stosujemy czcionkę o s ta łe j szerokości znaków bez żadnych wyróżnień. Pogrubienie w kodzie stosujemy po to , by zaznaczyć, że je s t wyjątkowo ważne w aktualnym kontekście albo by pokazać zmiany w stosunku do poprzedniego przykładowego fragmentu.
Kod źródłowy
| 23
Kod źródłowy W trakcie czytania wszystkie przykłady kodu źródłowego możesz wpisywać do swojego środowiska programistycznego ręcznie albo możesz skorzystać z plików towarzyszących tej książce. Można je pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Na początku każdego rozdziału w razie możliwości wprowadzamy implementację wzorca w podstawowej wersji Javy. Dalej pokazujemy też implementację w Javie EE, którą da się skompilować tylko przy użyciu JDK dla Javy EE i uruchomić na serwerze aplikacji zgodnym z tą technologią. Pliki do pobrania są skompresowane w formacie ZIP, więc po pobraniu należy je wypakować przy użyciu odpowiedniego programu.
Errata Staramy się, aby wyeliminować z naszych tekstów i przykładów kodu wszystkie błędy, ale nikt nie jest idealny. Jeśli więc znajdziesz jakiś błąd w jednej z naszych książek, np. literówkę albo niepoprawny fragm ent kodu, będziemy wdzięczni za informację. Wysyłając nam erratę, możesz oszczędzić innym czytelnikom wielu nerwowych godzin. Jednocześnie pomagasz nam podnosić jakość naszych książek. Aktualna errata do tej książki znajduje się na stronie: http://www.helion.pl/ksiazki/javeez.htm. Wejdź na tę stronę i jeśli nie znajdziesz tam zauważonego błędu, wypełnij formularz zgłaszania erraty. Sprawdzimy Twoją informację i jeśli uznamy, że masz rację, opublikujemy ją na stronach erraty i uwzględnimy w następnym wydaniu książki.
Kontakt z autorami Jeśli masz jakieś pytania dotyczące zawartości tej książki, kodu lub innych kwestii związanych z tą publikacją, możesz napisać bezpośrednio do autorów za pośrednictwem ich blogów lub Twittera. M u rat Yener: ^
blog — devchronicles.com,
^
T w itter — @yenerm.
Alex Theedom : ^
blog — alextheedom.com,
^
T w itter — @alextheedom.
24 | JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
I Wprowadzenie do wzorców projektowych w Javie EE
^
Rozdział 1. Krótki przegląd wzorców projektowych
^
Rozdział 2. Podstawy Javy EE
1 Krótki przegląd wzorców projektowych
ZAWARTOŚĆ ROZDZIAŁU:_______ > przegląd wzorców projektowych; > zwięzła historia wzorców projektowych i powód, dla którego są takie ważne; > zastosowanie wzorców projektowych w realnym świecie; > historia i ewolucja technologii Java Enterprise Edition; > pojawienie się biznesowych wzorców projektowych; > ewolucja wzorców projektowych w otoczeniu biznesowym; > dlaczego i jak wzorce stały się antywzorcami.
Książka ta m a na celu wypełnienie luki między tradycyjną implementacją wzorców projektowych w Javie SE i ich implementacją w Javie EE. Początkujący w dziedzinie wzorców projektowych szybko nauczą się z tej książki praktycznego wykorzystania wzorców, ponieważ znajdą w niej łatwe do zrozumienia objaśnienia i wiele przykładów działającego kodu źródłowego. Bardziej doświadczeni program iści znający wzorce projektowe i umiejący je implementować, ale niewiedzący, jak to zrobić w Javie EE, znajdą w tej książce dokładnie to, czego im trzeba. Każdy rozdział zawiera opis implementacji tradycyjnej i nowej, często prostszej implementacji w Javie EE. Dla ekspertów od Javy książka może być rzetelnym źródłem informacji o im plementowaniu większości powszechnie używanych wzorców projektowych w Javie SE i Javie EE.
28
I
ROZDZIAŁ 1. Krótki przegląd wzorców projektowych
W książce opisano najczęściej używane wzorce projektowe Javy EE i pokazano sposoby ich implementacji na tej platformie. Na początku każdego rozdziału znajduje się opis jednego wzorca z wyjaśnieniem przeznaczenia i sposobu użycia. Potem przedstawiamy sposób jego implementacji w Javie SE oraz szczegółowy opis jej działania. Następnie pokazujemy też, jak dany wzorzec jest implementowany w Javie EE, oraz opisujemy typowe sposoby jego użycia, korzyści z jego stosowania i pułapki, w jakie m ożna wpaść. Wszystkim objaśnieniom towarzyszą szczegółowe przykłady kodu, które można pobrać z serwera FTP wydawnictwa. Na końcu rozdziału zawsze znajdują się informacje końcowe i zwięzłe podsumowanie wiadomości. W niektórych rozdziałach dodaliśmy ciekawe i czasami dość trudne ćwiczenia, które można wykonać, aby sprawdzić, czy dobrze się zrozumiało dany wzorzec.
Czym jest wzorzec projektowy Wzorce projektowe są „opisami mających ze sobą kontakt obiektów i klas, które dopasowuje się do własnych potrzeb w celu rozwiązania ogólnych problemów projektowych w konkretnym kontekście” — Ba n
da
Cz w
o rg a
W zorce projektow e to gotowe rozwiązania typowych problemów odnoszących się do projektowania aplikacji. Wzorce projektowe programowania obiektowego rozwiązują raczej problemy dotyczące tworzenia obiektów i interakcji między nimi, nie zaś wielkoskalowych zagadnień związanych ogólnie z architekturą oprogramowania. Wizualnie wzorce projektowe z reguły przedstawia się za pomocą diagram ów klas obrazujących ich zachowania i występujące między nimi relacje. Na rysunku 1.1 pokazano taki typowy diagram. Ukazano na nim relacje między trzem a klasami. Podklasy CheckingAccount i SavingsAccount dziedziczą po abstrakcyjnej klasie nadrzędnej BankAccount. BankAccount ow ner: String balance: Dollars deposit (am ount: Dollars) withdrawal (am ount: Dollars)
1r Checking Account
1r SavingsAccount
InsufficlentFundsFee: Dollars
annuallnterestRate: Percentage
processCheck (checkToProcess: Check) withdrawal (am ount: Dollars)
depositMonthlylnterestf) withdrawal (am ount: Dollars)
Rysunek 1.1. Diagram klas przedstawiający dziedziczenie Po takim diagramie przedstawiamy najprostszą implementację w Javie. Na rysunku 1.2 widać przykład wzorca Singleton, którego opis znajduje się w jednym z dalszych rozdziałów.
Czym jest wzorzec projektowy
| 29
Singleton instance: Singleton - Singleton () + getlnstance (): Singleton
Rysunek 1.2. Diagram klas wzorca projektowego Singleton Poniżej znajduje się przykład najprostszej możliwej implementacji. public enum MySingletonEnum { INSTANCE; public void doSom ethingInteresting() {} }
Jak odkryto wzorce i do czego są potrzebne W zorce projektowe są popularne od ukazania się w 1994 r. słynnej książki Bandy Czworga (ang. Gang o f Four — GoF; do bandy tej należą: Erich Gamma, Richard Helm, Ralph Johnson oraz John Vlissides) Design Patterns: Elements o f Reusable Object-Oriented Software1, w której autorzy opisali wypróbowane rozwiązania najczęściej występujących problemów programistycznych. T a niezwykle ważna w bibliotece programisty pozycj a zawiera opisy różnych technik programistycznych i pułapek oraz 23 wzorców projektowych dotyczących programowania obiektowego. Wzorce te są podzielone na trzy kategorie: konstrukcyjne, strukturalne i behawioralne. Ale po co to wszystko? Dlaczego nagle wszyscy stwierdzili, że nie mogą żyć bez wzorców projektowych? Tak naprawdę to nic nie zdarzyło się nagle. Program owanie obiektowe zaczęło zyskiwać popularność w latach 80., kiedy pojawiło się kilka języków zbudowanych według tych zasad. Do dziś z tam tych czasów przetrwały w dobrej kondycji np. języki: Smalltalk, C++ i Objective C. Ale oczywiście z nową technologią przyszły też nowe problemy. Obiektowość, w odróżnieniu od program owania proceduralnego, rozwinęła się bardzo szybko i początkowo po prostu nie było wiadomo, co w przyszłości się sprawdzi, a co nie. Mimo że wzorce projektowe rozwiązują wiele problemów (np. pozwalają wyeliminować tzw. kod spaghetti) typowych dla proceduralnych języków programowania, jak C i COBOL, języki obiektowe nie są też pozbawione wad. Na przykład język C++ rozwinął się bardzo szybko, a że jest wyjątkowo skomplikowany, wielu używających go programistów wpadło w najprzeróżniejsze kłopoty, jak: wycieki pamięci, nieprawidłowe wykorzystanie obiektów, niebezpieczne posługiwanie się pam ięcią oraz brak możliwości pracy ze starym kodem. Ale w większości napotykanych problemów można było zauważyć pewne powtarzalne wzorce, więc nietrudno się domyślić, że ktoś już gdzieś przynajmniej niektóre z nich rozwiązał. Czasy początków obiektowości sięgają ery przedinternetowej, więc trudniej niż dzisiaj było opublikować swoje spostrzeżenia, aby inni mogli się o nich dowiedzieć. Dlatego właśnie Bandzie Czworga trochę zeszło z przygotowaniem zbioru gotowych wzorców rozwiązań typowych problemów programistycznych.
1 Polskie wydanie: W zorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, Helion, 2010.
30
| ROZDZIAŁ 1. Krótki przegląd wzorców projektowych
Wzorce w realnym świecie Wzorce projektowe są niezwykle przydatnymi i dokładnie sprawdzonymi rozwiązaniami problemów, na które natyka się każdy programista. Stanowią skondensowaną formę wieloletniego doświadczenia i zbiorowej wiedzy wielu programistów, a dzięki otrzymanym nazwom ułatwiają programistom komunikację i objaśnianie rozmaitych zagadnień. W zorce projektowe nie są jednak magiczną różdżką. Nie przedstawiają gotowych implementacji, jak systemy szkieletowe czy zestawy narzędzi. Nie należy też ich używać tylko dlatego, że fajnie się nazywają albo żeby zaimponować szefowi czy współpracownikom, bo w ten sposób m ożna łatwo uzyskać przerost formy nad treścią i zamiast doskonałego stworzyć pełen błędów niewydajny system, który na dodatek będzie trudny w obsłudze. Większość wzorców ułatwia pokonywanie problemów projektowych, opisuje gotowe rozwiązania typowych problemów oraz usprawnia program istom komunikację za pom ocą powszechnie znanego słownictwa. Ale powinno się ich używać tylko wtedy, gdy naprawdę jest taka potrzeba. Pierwsza klasyfikacja wzorców projektowych zawierała trzy grupy: ^
W zorce k o n stru k cy jn e — wzorce opisujące sposoby tworzenia obiektów, inicjacji obiektów oraz wybierania klas. Przykładami z tej grupy są Singleton (rozdział 4., „Wzorzec Singleton”) i Fabryka (rozdział 6., „Wzorzec Fabryka”).
^
W zorce behaw ioralne — wzorce opisujące sposoby komunikacji, przesyłania powiadomień oraz interakcji między obiektami. Przykładem z tej grupy jest Obserwator (rozdział 11., „Wzorzec Obserwator”).
^
W zorce stru k tu raln e — wzorce opisujące kwestie związane z relacjami między klasami i obiektami, reprezentujące wytyczne dotyczące łączenia i wykorzystywania spokrewnionych obiektów razem w celu uzyskania pożądanych efektów. Dobrym przykładem z tej grupy jest wzorzec Dekorator (rozdział 7., „Wzorzec Dekorator”).
Wzorce projektowe to także zasób słownictwa zrozumiałego dla wszystkich programistów. Przy użyciu ich nazw programiści mogą łatwiej i skuteczniej się porozumiewać, nie musząc ciągle wynajdywać koła na nowo. Chcesz pokazać kumplowi, jak zamierzasz dodać do program u dynamiczne zachowanie w czasie działania? Już nie musisz robić wyszukanych rysunków i wyjaśniać nieporozumień. Teraz to jest proste. Wystarczy powiedzieć parę słów, np.: „Użyję wzorca Dekorator!”, a kolega od razu domyśli się, o co Ci chodzi, i nie będzie trzeba jakichkolwiek dodatkowych wyjaśnień. Jeśli znasz dany wzorzec i umiesz go stosować w odpowiednim kontekście, to jesteś na dobrej drodze do stworzenia solidnej i łatwej w obsłudze aplikacji.
WARTO PRZECZYTAĆ Warto przeczytać książkę Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — Helion, 2010) albo Wzorce projektowe. Rusz głową! (Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra — Helion, 2010). Obie są doskonałym uzupełnieniem bieżącej publikacji i zawierają bezcenne informacje dla tych, którzy uczą się wzorców projektowych.
Podstawy wzorców projektowych
| 31
Podstawy wzorców projektowych Jedną z kluczowych cech wzorców projektowych jest to, że ich nadużywanie lub stosowanie bez potrzeby prowadzi do poważnych kłopotów. Gdy program ista nauczy się jakiegoś wzorca, to czuje przemożną potrzebę stosowania go wszędzie gdzie się tylko da. Skutkiem tego często jest rozdęcie kodu singletonami, opakowaniami albo nadmiernie skomplikowanymi dekoratorami. Wzorce projektowe to rozwiązania problemów, więc jeśli dany problem nie występuje, nie ma sensu wykorzystywać rozwiązującego go wzorca. Na przykład zastosowanie dekoratora tylko dlatego, że istnieje cień ryzyka, że w przyszłości zachowanie obiektu się zmieni, tylko niepotrzebnie skomplikuje dziś kod i zamieni w koszmar życie każdego, kto za jakiś czas zechce coś w nim pozmieniać.
Wzorce w rozwiązaniach dla biznesu Java 1.0 została wydana w 1996 r. i szybko zdobyła popularność. Był to po prostu doskonały czas na wprowadzenie nowego języka programowania, wolnego od skomplikowanych mechanizmów zarządzania pamięcią, wskaźników i trudnej do pojęcia składni języków C i C++. Java była w miarę łatwa do nauki, dzięki czemu program iści szybko sobie ją przyswajali i nie potrzebowali dużo czasu, aby zacząć pisać w niej programy. Ale do popularności Javy przyczynił się jeszcze jeden czynnik — aplety. A plet to niewielka aplikacja działająca na stronie internetowej niezależnie od przeglądarki i wzbogacająca funkcjonalność tej strony w sposoby niemożliwe do osiągnięcia przy użyciu samych technologii HTML i CSS. Na przykład za pomocą apletu można było stworzyć interaktywny wykres albo kanał strum ieniowania wideo. Błyskawiczny rozwój internetu sprawił, że statyczne strony internetowe szybko odeszły do lamusa. Przeciętny użytkownik chciał oglądać coraz ładniejsze, lepsze i szybsze prezentacje. I wtedy pojawiły się aplety, które zam ieniły strony internetow e w interaktywne aplikacje z różnym i efektami specjalnymi. Statyczne strony internetowe stały się przeszłością. W krótce symbol Javy Duke został symbolem nowoczesnej strony internetowej. Ale w internecie nic nie jest trwałe. Użytkownicy chcieli coraz więcej, a aplety bardzo słabo przystosowywały się do nowych warunków, przez co ich popularność z czasem wygasła. Mimo to aplety były m otorem napędzającym popularność i rozprzestrzenianie się platformy Javy. Dziś (w chwili pisania tej książki) Java wciąż jest jednym z dwóch najpopularniejszych języków programowania na świecie2.
Od Javy do Javy dla biznesu Po pojawieniu się standardowej wersji Javy (Java Standard Edition — Java SE) firm a IBM w 1997 r. wprowadziła Enterprise JavaBeans (EJB), technologię, którą firma Sun zaadaptowała w 1999 r. i wcieliła do platform y Enterprise Java Platform (J2EE) 1.2. W roku 1998 i przed pojawieniem się J2EE3 firm a Sun opublikowała profesjonalną wersję Javy o nazwie JPE. Jednak producenci oprogram owania i programiści zainteresowali się Javą dla przedsiębiorstw dopiero po powstaniu technologii EJB. Od chwili pojawienia się J2EE 1.3 w 2001 r. Java stała się najważniejszym graczem w biznesie, a jej pozycję ugruntowała wydana w 2003 r. wersja J2EE 1.4. 2 W ed łu g in d ek su T IO B E Java jest n a d rugim m iejscu za językiem C; h ttp://w w w .tiobe.com /index.php/content/paperinfo/tpci/index.htm l. 3 D o w ersji 5 Java EE była nazyw ana J2EE. O d tam tej p o ry J2EE oznacza tech n o lo g ie sprzed Javy EE 5.
32
I
ROZDZIAŁ 1. Krótki przegląd wzorców projektowych
W ersja 1.4 była jedną z najbardziej innowacyjnych wersji w historii Javy. Została powszechnie zaadaptowana, a jej popularność nie słabła przez wiele lat, nawet po pojawieniu się nowszych wersji. Producenci oprogramowania i korporacje ociągały się z wprowadzaniem zmian, mimo że wersja J2EE 1.4 pozostawiała wiele do życzenia. Korzystanie z niej m ożna porów nać do jeżdżenia po zakupy do warzywniaka m onster truckiem zamiast samochodem rodzinnym. Niewątpliwie była to potężna technologia, ale zbyt skomplikowana i rozdęta przez pliki XML. Ociężałe były zarówno szkielety, jak i kontenery. Mimo to technologia J2EE stała się najpopularniejszą platformą programistyczną dla przedsiębiorstw. Stało się tak dzięki pewnym jej cechom, które czyniły ją doskonałym wyborem do programowania aplikacji biznesowych. ^
Przenośność — maszyna w irtualna Javy (JVM) umożliwiała uruchamianie programów w Javie w każdym systemie operacyjnym. Programista mógł napisać program w Windowsie, przetestować go w Linuksie, a wdrożyć w Uniksie.
^
Bezpieczeństwo — technologia J2EE miała własny wbudowany model zabezpieczeń oparty na rolach.
^
T ransakcje — w J2EE była wbudowana obsługa transakcji.
^
Elem enty języka z J2SE — J2SE miała prostą składnię, automatyczny system odzyskiwania nieużywanej pamięci oraz doskonałe m echanizmy obiektowości.
Mimo to technologia J2EE nie była idealna. Skomplikowana struktura z wielkimi plikami konfiguracyjnymi w formacie XML szybko stała się źródłem wielu problemów.
Pojawienie się wzorców Javy dla przedsiębiorstw Skomplikowane modele program owania J2EE szybko wyprowadziły wiele projektów na manowce. Aplikacje zbudowane przy użyciu tej technologii często zawierały ogromne ilości kodu „zapychającego”, takiego jak: kod wyszukiwania JNDI, pliki konfiguracyjne XML i bloki tr y - c a tc h zajmujące i zwalniające zasoby JDBC. Pisanie i obsługiwanie takiego kodu wymagało mnóstwa zasobów, a poza tym program y te zawierały wiele błędów i miały m arną wydajność. Poziom złożoności implementacji logiki biznesowej miał zredukować model kom ponentów EJB, ale plan ten się nie powiódł. Model ten był po prostu zbyt skomplikowany i często nadużywany. Zaledwie po paru latach od pojawienia się platform y na konferencji JavaOne w 2000 r., Deepak Alur, John Crupi i Dan Malks wygłosili referat pt. Wzorce prototypowe dla platformy J2EE, w którym wprowadzili kilka wzorców rozwiązań typowych problem ów spotykanych przy projektow aniu aplikacji J2EE. Referat ten zam ieniono w wydaną w następnym roku książkę Core J2EE Patterns: Best Practices and Design Strategies4. Oprócz piętnastu powszechnie znanych autorzy opisali sześć nowych wzorców projektowych dla J2EE. Zaliczały się do nich: Obiekt Kontekstu i Kontroler Aplikacji dla warstwy prezentacyjnej, Usługa Aplikacji i Obiekt Biznesowy dla warstwy biznesowej oraz Magazyn Dom en i Broker Usług Sieciowych dla warstwy integracji. Niektóre z tych wzorców wyrosły z klasycznych wzorców Bandy Czworga, inne zaś są całkiem nowe i dotyczą wad technologii J2EE. W kolejnych latach pojawiło się kilka projektów i systemów szkieletowych, jak np. Apache Camel, które ułatwiły życie programistom aplikacji dla przedsiębiorstw.
4 D eepak A lur, D an M alks, John C rupi, Core J2EE Patterns: B est Practices and Design Strategies, wyd. 2, P rentice Hall, 2003.
Wzorce w rozwiązaniach dla biznesu
I 33
N iektórzy bardziej przebojowi postanow ili nawet porzucić J2EE i przejść na coś innego, np. Rod Johnson5 stworzył system szkieletowy Spring. System ten szybko zdobył popularność, która spowodowała też wielkie zmiany w nowym modelu programowania Javy EE. Dziś większość z tych wzorców nadal jest aktualna i powszechnie stosowana. Niektóre jednak w wyniku uproszczenia modelu programowania Javy EE stały się przestarzałe i wyszły z użycia.
Wzorce projektowe a wzorce biznesowe W zorce biznesow e różnią się od wzorców projektowych tym, że opisują rozwiązania problemów występujących w oprogram owaniu dla przedsiębiorstw, które to problemy znacznie różnią się od dręczących program istów aplikacji dla kom puterów osobistych. Pojawiła się nowa metodyka o nazwie SOA (ang. Service Oriented Architecture), która wprowadziła kilka zasad dotyczących budow ania dobrze zorganizowanych program ów biznesowych nadających się do wielokrotnego użytku. Podstawę tych zasad stanowią cztery założenia SOA Dona Boksa6. Opisują one typowe wymagania każdego biznesowego projektu.
CZTERY ZAŁOŻENIA SOA DONA BOKSA 1. Granice są wyraźne. 2. Usługi są autonomiczne. 3. Usługi dzielą schemat i kontrakt, nie klasę. 4. Zgodność usług determinuje zestaw reguł. Ale klasyczne wzorce projektowe też mają jeszcze sporo do zaoferowania. Pojawienie się Javy EE 5 spowodowało przywrócenie zainteresow ania Javą biznesową, której pole przez długi czas zawłaszczały systemy szkieletowe typu Spring i Struts. Jeszcze większym wydarzeniem było pojawienie się Javy EE 6, która stanow iła duży krok naprzód i stała się znów konkurencyjna. Dziś w Javie EE 7 większość klasycznych wzorców projektowych opisanych w książce Bandy Czworga jest w budow ana bezpośrednio w platform ę i gotowa do użycia w każdej chwili. W odróżnieniu od czasów J2EE większość z tych wzorców można zaimplementować przy użyciu adnotacji i bez potrzeby stosowania skomplikowanych plików konfiguracyjnych XML. T o ogromny postęp w porów naniu z tym, co było kiedyś, a dzięki tem u postępowi model programowania stał się znacznie prostszy. Jest kilka świetnych książek poświęconych wzorcom projektowym i nowym właściwościom Javy EE, ale brak chyba pozycji na tem at sposobu implementacji tych wzorców w Javie EE.
Stare dobre wzorce projektowe spotykają Javę EE Java od samego początku jest przyjazna wzorcom projektowym. Niektóre z nich są już nawet domyślnie zaimplementowane i gotowe do użytku, jak np. wzorzec Obserwator w Javie SE. W samej Javie też wykorzystywanych jest wiele wzorców projektowych. Na przykład wzorzec Singleton jest używany w klasach systemowych i klasach systemu wykonawczego, a kom paratory są doskonałym przykładem implementacji wzorca Strategia.
5 R od Johnson (@springrod) to pochodzący z A ustralii specjalista o d kom p u teró w oraz tw órca system u S pring F ram ew o rk i w spółzałożyciel SpringS ource; http://en.w ikipedia.org/w iki/R od_Johnson_(program m er). 6 D o n Box (@ donbox) jest w ybitnym inżynierem ; http://en.w ikipedia.org/w iki/D on_B ox.
34
| ROZDZIAŁ 1. Krótki przegląd wzorców projektowych
Podobnie jest w Javie dla przedsiębiorstw, a zwłaszcza w Javie EE, która także m a wbudowane implementacje wielu wzorców projektowych opisanych w książce Bandy Czworga. Większość z nich m ożna włączyć do użytku za pomocą łatwych w stosowaniu adnotacji. Zamiast więc wpatrywać się w diagramy klas i pisać kod zastępczy, każdy doświadczony program ista może włączyć wybrany wzorzec za pomocą paru linijek kodu. Czy to magia? Niezupełnie. Projekt systemu wykonawczego Javy EE jest nieco wyrafinowany, dzięki czemu system ten zapewnia wiele funkcji zależnych od platformy, na której działa. Większość funkcji wymaganych do zaimplementowania tych wzorców nie byłaby dostępna bez nadzbioru właściwości Javy EE, takich jak EJB czy CDI (ang. Context and Dependency Injection). Kontener Javy EE wykonuje większość pracy za program istę, dodając wiele wbudowanych usług i funkcji do serwera. W adą tego jest to, że serwerowe środowisko wykonawcze stało się ociężałe, zwłaszcza w porów naniu z podstawowymi serwerami sieciowymi, takimi jak Apache Tomcat. Niemniej jednak wszystko zmierza w kierunku poprawy i najnowsze kompilacje systemu wykonawczego w Javie EE 7 są już lżejsze. Dlaczego więc programiści wciąż potrzebują wzorców projektowych w aplikacjach dla przedsiębiorstw? T ak naprawdę wzorce te są teraz jeszcze bardziej potrzebne niż kiedyś. Większość aplikacji biznesowych tworzą dla korporacji różne zespoły program istów i niektóre części tych program ów muszą być wielokrotnie wykorzystywane. W efekcie rozwiązania problemów nie pozostają w naszych rękach czy w niewielkich zespołach, ale są udostępniane na zewnątrz w całej korporacji, a czasami nawet poza nią (jeśli projekt m a otwarty kod źródłowy). Nie jest trudno wprowadzić źle zaprojektowaną aplikację i sprawić, aby stała się korporacyjną tradycją albo strategią programowania. Jako że biblioteki, klasy pomocnicze i interfejsy programistyczne (API) są dostępne dla większej liczby programistów, złamanie zgodności i wprowadzanie radykalnych zmian stało się jeszcze trudniejsze. Zm iana jednego typu zwrotnego czy nawet dodanie m etody do interfejsu może wywołać awarię we wszystkich projektach wykorzystujących dany kom ponent. Oczywiście w program owaniu aplikacji dla przedsiębiorstw powinno się utrzymywać ściślejszą dyscyplinę i dokładniej koordynować pracę różnych zespołów. Wzorce projektowe są dobrym rozwiązaniem tego problem u. Jednak wciąż niewielu program istów wykorzystuje w pełni klasyczne wzorce projektowe, mimo że niektórzy z nich używają Javy EE od wersji 5.0. Choć wzorce biznesowe rozwiązują wiele problemów, pierwotne wzorce projektowe też jeszcze są przydatne. Są to przecież dobrze sprawdzone i wypróbowane rozwiązania, które przetrwały próbę czasu i zostały zaimplementowane w prawie wszystkich obiektowych językach programowania. Ponadto większość z tych wzorców jest już zintegrowana z platformą Java EE, dzięki czemu nie trzeba pisać ich pełnej implementacji. W niektórych przypadkach może być potrzebna drobna konfiguracja XML, ale większość wzorców m ożna zaimplementować przez dodanie adnotacji do klasy, m etody lub zmiennej składowej. Chcesz utworzyć singleton? W takim razie dodaj na początku pliku klasy adnotację @Singleton. Chcesz zaimplementować fabrykę? Dodaj adnotację @Produces, a metoda stanie się fabryką określonego typu zwrotnego. Java EE wyznacza też standardy. Adnotacja @ Inject służy jako domyślna implementacja, którą można mieszać z prawie każdym innym systemem szkieletowym (Spring), ponieważ w tych systemach używane są takie same adnotacje.
Podsumowanie
I 35
Kiedy wzorce stają się antywzorcami W zorce projektowe reprezentują m ądrość zbiorową, ale to nie znaczy, że trzeba ich używać wszędzie. Jak to zgrabnie ujął Abraham Maslow7: „Jeśli do dyspozycji masz tylko młotek, to każdy problem wydaje ci się gwoździem”. Jeżeli wszystkie problemy będziesz rozwiązywać przy użyciu znanych Ci wzorców, to po prostu nie będą to dobre rozwiązania, a co gorsza mogą powodować kolejne problemy. Co więcej, nieuzasadnione stosowanie wzorców potęguje złożoność systemu i spowalnia jego działanie. To, że lubisz wzorzec Dekorator, nie znaczy, że musisz go implementować w każdym obiekcie. Wzorce sprawdzają się najlepiej wtedy, gdy ich zastosowania wymaga sytuacja i charakterystyka problemu.
Podsumowanie Java i wzorce projektowe przebyły bardzo długą drogę, aby znaleźć się w tym miejscu, w którym są. Kiedyś były kompletnie odrębne, ale teraz są ściśle związane z Javą Enterprise Edition. Aby zrozumieć ten bliski związek, trzeba znać historię obu stron, której opis znajduje się właśnie w tym rozdziale. Dowiedziałeś się, jakie były trudne początki technologii J2EE oraz jak książka Bandy Czworga rzuciła światło na 23 popularne wzorce projektowe. Dowiedziałeś się też, że za plecami Javy powstały systemy szkieletowe, takie jak Spring, które przejęły sporą część jej pola, ale przebudowane nowe wersje Javy EE zaczynają się odgryzać i odzyskiwać należne im miejsce. Dzięki informacjom z tej książki będziesz sprawnie i efektywnie rozwiązywać typowe problem y projektowe napotykane podczas tw orzenia program ów . Możesz spać spokojnie, wiedząc, że lata walki technologii Java Enterprise Edition w połączeniu ze zbiorową mądrością zgromadzoną we wzorcach projektowych zapewniły Ci solidne i zarazem elastyczne środowisko programowania. Korzystaj z cennych wskazówek i używaj zawartej w nich mądrości we wszystkich projektach.
7 A b rah am H a ro ld M aslow (1908 - 1970) — am erykański psycholog.
36 | ROZDZIAŁ 1. Krótki przegląd wzorców projektowych
2 Podstawy Javy EE
ZAWARTOŚĆ ROZDZIAŁU:_______ > wprowadzenie do podstawowych pojęć Javy EE; > opis wielowarstwowej struktury aplikacji biznesowej; > opis serwerów obsługujących Javę EE i objaśnienie profilu sieciowego; > konwencje przed konfiguracją; > CDI (ang. Context and Dependency Injection); > interceptory.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r02, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. Model program owania Javy EE od czasów J2EE został znacznie uproszczony. Pliki deskrypcyjne XML zastąpiły adnotacje, w miejsce niewygodnej ręcznej konfiguracji weszły konwencje, a wstrzykiwanie zależności pozwoliło ukryć mechanizmy tworzenia i wyszukiwania zasobów. Programiści muszą zmienić swoje podejście do projektowania i pisania kodu źródłowego. Teraz o wiele łatwiej tworzy się aplikacje biznesowe przy użyciu Javy EE. Wystarczy do tego zwykły obiekt Javy (POJO) z m etadanym i w adnotacjach. W zależności od tego, których adnotacji się użyło, obiekt staje się ziarnem JavaBeans (EJB — stanowym lub bezstanowym), serwletem, ziarnem JSF, obiektem trwałości (ang. persistence entity), singletonem albo usługą sieciową typu REST. Wiele z tych usług można również zadeklarować przy użyciu kodu XML w deskryptorze wdrożenia.
38
I
ROZDZIAŁ 2. Podstawy Javy EE
Na listingu 2.1 przedstawiono sposób zamiany zwykłego obiektu w ziarno singletonowe tworzone i inicjowane przy urucham ianiu program u i podlegające zarządzaniu przez kontener. W tym celu wystarczyło dodać adnotacje @Singleton i @ Startup do klasy oraz @ PostConstruct do metody inicjującej. Szczegółowy opis sposobu użycia tych adnotacji znajduje się w rozdziale 4., „Wzorzec Singleton”. Listing 2.1. Wystarczy parę adnotacji, aby zamienić zwykły obiekt w singletonowe ziarno podlegające zarządzaniu przez kontener package com .devchronicles.b asicso fj2 ee; import jav a.u til.M ap ; import java.util.H ashM ap; import jav ax .annotation.PostC onst r u c t; import jav a x .e jb .S in g le to n ; import ja v a x .e jb .S ta rtu p ; @Startup @Singleton public c la ss CacheSingletonBean { p riv a te Map
myCache; @PostConstruct public void s t a r t () { myCache = new HashMap (); } public void addU ser(Integer id , S tring name) { myCache.put(id, name); } public S tring getName(Integer id) { return myCache.get(id); } } Cele Javy EE nie uległy zmianie. Technologia ta nadal m a za zadanie zaspokajać potrzeby program istów i przedsiębiorstw w zakresie tworzenia rozproszonych i transakcyjnych aplikacji cechujących się dużą szybkością działania, bezpieczeństwem i wysokim stopniem niezawodności. Platforma Java EE m a ułatwić tworzenie dużych, wielowarstwowych aplikacji oraz zapewnić ich niezawodność i bezpieczeństwo.
Architektura wielowarstwowa Architektura aplikacji Java EE jest podzielona na warstwy: klienta, logiki biznesowej (ang. middle tier — na którą składają się warstwa sieciowa i warstwa biznesowa) i informacyjną, zwaną EIS (ang. Enterprise Information Systems). Podział aplikacji na osobne warstwy zapewnia większą elastyczność i lepsze możliwości adaptacyjne. W razie potrzeby zamiast zmieniać całą aplikację, można dodać lub zmodyfikować tylko określoną warstwę. Każda warstwa jest fizycznie oddzielona od pozostałych i znajduje się na przeznaczonych tylko dla niej komputerach. W aplikacji sieciowej warstwa kliencka jest rozproszona globalnie.
Warstwa kliencka
| 39
Java EE działa w obrębie warstwy logiki biznesowej, chociaż styka się zarówno z warstwą kliencką, jak i EIS. Odbiera żądania od aplikacji warstwy klienckiej. Jej kom ponent sieciowy przetwarza te żądania i przygotowuje odpowiedzi, które następnie wysyła z powrotem do warstwy klienckiej. Natom iast składnik biznesowy stosuje logikę biznesową przed zapisaniem danych w warstwie EIS. Kom ponenty warstwy logiki biznesowej płynnie kom unikują się z warstwą EIS i przygotowują odpowiedź dla warstwy klienckiej. Na rysunku 2.1 przedstawiono schematycznie, jak wygląda taka wielowarstwowa architektura.
Serwer Java EE
Warstwa EIS Serwer baz danych
Rysunek 2.1. Wielowarstwowa architektura ukazująca interakcje między warstwami
Warstwa kliencka Warstwę kliencką najczęściej stanowi przeglądarka internetowa łącząca się z serwerem Java EE za pośrednictwem protokołu HTTP, chociaż w istocie może to być każda aplikacja na jakimkolwiek komputerze, pod warunkiem że pełni funkcję klienta w relacji klient-serwer. Aplikacja kliencka wysyła do serwera żądanie zasobu. Serwer przetwarza to żądanie i zwraca odpowiedź. Tak najczęściej wygląda relacja między klientem i serwerem. UWAGA Warstwę kliencką często nazywa się też warstwą prezentacyjną.
40
I
ROZDZIAŁ 2. Podstawy Javy EE
Warstwa logiki biznesowej Środkową warstwę, logiki biznesowej, stanowi serwer Java EE, który dostarcza dwa logiczne kontenery: sieciowy i EJB. Odpowiadają one z grubsza komponentowi sieciowemu i komponentowi biznesowemu. Każdy z nich m a inne, choć mogące się częściowo pokrywać, zadania. Do oddzielania logiki odpowiedzialnej za generowanie widoku należącej do komponentu sieciowego od logiki modelowania danych należącej do kom ponentu biznesowego często stosuje się wzorzec Model - W idok - Kontroler (ang. Model-View-Controller — M VC). Szczegółowy opis sposobu implementacji tego wzorca znajduje się w rozdziale 14., „Wzorzec Model - W idok - Kontroler”.
Komponent sieciowy Komponent sieciowy obsługuje interakcje zachodzące między warstwą kliencką a kom ponentem biznesowym. Jego zadaniem jest odbieranie żądań zasobów od warstwy klienta. Żądania takie mogą zawierać dane wprowadzone przez użytkownika, np. nazwę użytkownika i hasło albo informacje rejestracyjne. Żądanie zostaje przetworzone i w razie potrzeby kom ponent sieciowy nawiązuje współpracę z kom ponentem biznesowym. Odpowiedź jest przygotowywana dynamicznie w jednym z kilku formatów (jeśli nadawcą żądania jest przeglądarka internetowa, to odpowiedź najczęściej jest wysyłana w postaci strony HTML), a następnie zostaje wysłana do klienta. Kom ponent sieciowy utrzymuje stany użytkowników w sesji i może nawet wykonywać elementy logiki biznesowej oraz tymczasowo zapisywać dane w pamięci. W komponencie sieciowym najczęściej wykorzystywane są technologie dotyczące obsługi interakcji między warstwami klienta i logiki biznesowej oraz tworzenia odpowiedzi. Serwlety kierują sieciowym przepływem sterowania i obsługują interakcje, podczas gdy strony JSP (ang. JavaServer Pages), EL (ang. Expression Language) i biblioteka JSTL (ang. JavaServer Pages Standard Tag Library) przygotowują odpowiedzi dla klienta. To tylko niektóre z technologii, jakich można używać w komponencie sieciowym. Pełna lista została przedstawiona na rysunku 2.2. UWAGA Warstwa logiki biznesowej bywa też nazywana: warstwą środkową, warstwą dostępu do danych oraz warstwą aplikacji.
Warstwa EIS Na warstwę EIS składają się jednostki przechowywania danych często będące bazami danych, ale mogą to być także dowolne zasoby dostarczające informacje. Równie dobrze może to być też przestarzały system albo system plików. UWAGA Warstwa EIS bywa też nazywana: warstwą danych, warstwą trwałości, warstwą informacji oraz warstwą integracji.
Serwery Java EE | 41
Pełne wym agania produktu2 Java API for W ebSocket
Dokum ent JSR
O pcjonalny
Profil sieciowy*
Now ość w Javie EE 7
Kontener sieciow y
Kontener EJB
JSR 356
Java API for JSO N Processing
JSR 353
Java Servlet 3.1
JSR 340
JavaServer Faces 2.2
JSR 344
Expression L an gu age 3.0
JSR 341
JavaServer Pages 2.3
JSR 245
Standard Tag Library for JavaServer Pages (JSTL) 1.2
JSR 52
Batch A pplications for the Java Platform
JSR 352
Concurrency Utilities for Java EE 1.0
JSR 236
Contexts and D e pende ncy Injection for Java 1.1
JSR 346
De pende ncy Injection for Java 1.0
JSR 330
Bean Validation 1.1
JSR 349
Enterprise JavaBeans 3.2 (z wyjątkiem ziaren encyjnych EJB i pow iązanego języka EJB QL, które są opcjonalne)
JSR 345
M anaged Beans 1.0
JSR-316
Interceptors 1.2
JSR 318
Java EE Conne ctor Architecture 1.7
JSR 322
Java Persistence 2.1
JSR 338
Com m on A nnotations for the Java Platform 1.2
JSR 250
Java M essage Service API 2.0
JSR 343
Java Transaction API (JTA) 1.2
JSR 907
JavaMail 1.5
JSR 919
Java API for RESTful Web Services (JAX-RS) 2.0
JSR 339
Im plem enting Enterprise W eb Services 1.4
JSR 109
Java API for XM L-Based Web Services (JAX-W S) 2.2
JSR 224
Web Services Metadata for the Java Platform
JSR 181
Java API for XM L-Based RPC (JAX-RPC) 1.1
JSR 101
Java API for XML Registries (JAXR) 1.0
JSR 93
Java A uthentication Service Provider Interface for Containers 1.1
JSR 196
Java Authorization Contract for Containers 1.5
JSR 115
Java EE Application Deploym ent 1.2
JSR 88
J2EE M anagem ent 1.1
JSR 77
D e b u g g in g Support for Other Lan gu age s 1.0
JSR 45
Java Architecture for XML Binding (JAXB) 2.2
JSR 222
1
1
1. Enterprise JavaBeans (EJB) 3.2 Lite. 2. Źródło: Java Platform, Enterprise Edition 7 (Java EE 7), JSR 342, EE.9.7 Full Java EE Product Requirements. 3. Źródło: Java Platform, Enterprise Edition 7 (Java EE 7), Web Profile Specification, JSR 342, WP.2.1 Required Components.
Rysunek 2.2. Technologie wykorzystywane w komponentach sieciowym i biznesowym
Serwery Java EE Jak już wiesz, warstwa logiki biznesowej zawiera serwer Java EE zapewniający funkcjonalność Javy EE potrzebną aplikacji biznesowej. Java EE opiera się na 30 standardach zwanych dokumentami JSR (ang. Java Specification Request — http://www.oracle.com/technetwork/java/javaee/tech/index.html). W szystkie te specyfikacje przechodzą przez społecznościowy proces recenzowania (JCP) i dopiero po jego zakończeniu zostają przyjęte jako część Javy EE. Proces JCP jest otwarty, dzięki czemu każdy, kto chce, może brać w nim udział i zgłaszać swoje uwagi, a nawet proponow ać własne specyfikacje JSR (https://www.jcp.org/en/home/index).
42
I
ROZDZIAŁ 2. Podstawy Javy EE
Wszystkie te specyfikacje są połączone w jeden pakiet i reprezentują technologie, które musi zaimplementować każda aplikacja pretendująca do spełnienia wymagań Javy EE. Ponadto firma Oracle wymaga, aby każda aplikacja serwerowa przechodziła testy Technology Compatiblity Kit (TCK). Jest to zbiór trudnych testów sprawdzających, czy aplikacja serwerowa działa zgodnie z wymogami specyfikacji. Dzięki tem u każda aplikacja zgodna ze specyfikacjami Javy EE może być wdrożona i uruchom iona na każdej aplikacji Java EE. W chwili pisania tej książki potwierdzenie pełnej zgodności z Javą EE 7 miały trzy serwery aplikacji: GlassFish Server Open Source Edition 4.0 (http://glassfish.java.net), W ildFly 8.0.0 (http://wildfly.org) oraz TMAX JEUS 8 (http://tmaxsoft.com/product/jeus/certification/). Natomiast z Javą EE 6 zgodnych jest 11 serwerów (http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Java_EE_6_certified).
Profil sieciowy Javy EE Profil sieciowy Javy EE to zbiór najbardziej niezbędnych technologii do tworzenia sieciowych aplikacji biznesowych. Profil ten redukuje rozm iar i poziom złożoności platformy tylko do tych technologii, które są potrzebne do utworzenia nowoczesnej aplikacji sieciowej. Jest to kompletny zestaw technologii związanych z przepływem pracy i podstawową funkcjonalnością (Servlet), prezentacją (JSF i JSP), logiką biznesową (EJB Lite), transakcjami (JTA), przechowywaniem danych (JPA), nowymi gniazdam i sieciowymi itd. Brak w nim wielu technologii typowo biznesowych, jak: Concurrency Utilities, Java Message Services, JAX-RPC, JAXR i JAX-WS. Kompletny wykaz technologii należących do profilu sieciowego znajduje się na rysunku 2.2.
Podstawowe zasady Javy EE Na podstawowe zasady Javy EE składa się kilka paradygmatów i wzorców projektowych, które odgrywają kluczową rolę dla sposobu tw orzenia aplikacji biznesowych. Sercem Javy EE jest paradygmat projektowy polegający na przedkładaniu konwencji nad konfigurację — sposób na uproszczenie procesu tworzenia aplikacji biznesowej bez tracenia elastyczności i zaciemniania przeznaczenia jej kodu źródłowego. Nie jest to nowy pomysł, ponieważ jest już od pewnego czasu z powodzeniem stosowany w Grails, Ruby on Rails i Spring Boot — w niektórych technologiach wykorzystuje się go od ponad dekady. Na szczęście trafił też do rdzenia Javy EE, dzięki czemu pomaga pisać piękny kod także program istom z tej branży. W Javie EE dobrze wykorzystywany jest też model komponentowy, na który składają się takie elementy, jak: encje (ang. Entities), ziarna JavaBeans, ziarna EJB, ziarna zarządzane (ang. Managed Beans), serwlety, SOAP oraz REST-owe usługi sieciowe. Wszystkie te składniki mogą być „wstrzykiwalnymi” zależnościami. Kontener zarządza ich cyklem eksploatacji (od utworzenia egzemplarza do destrukcji) — niezależnie od tego, czy są związane z kontekstem, czy nie — oraz poprzez wstrzykiwanie zależności zapewnia ich odłączenie od kom ponentów zależnych. Aplikacja złożona z luźno powiązanych składników jest rozszerzalna — stare klasy można wymienić na nowe bez potrzeby zmieniania czegokolwiek w klasach, które są od niej zależne. Wstrzykiwanie zależności odłącza obiekt od jego zależności, podczas gdy interceptory odłączają kwestie biznesowe od technicznych i przekrojowych. Do technologicznych kwestii m ożna zaliczyć wydajność i rejestrację informacji w dziennikach, a kwestią przekrojową jest np. bezpieczeństwo.
Konwencja przed konfiguracją
| 43
Konwencja przed konfiguracją Zgodnie z konwencją nazwy wszystkich klas pow inny zaczynać się wielką literą. Nie jest to obowiązkowe, ponieważ klasa o nazwie zaczynającej się od małej litery też przejdzie kompilację, ale stosowanie na początku nazw klas wielkiej litery sprawia, że kod jest bardziej czytelny i łatwiejszy w obsłudze serwisowej. W środowisku programistycznym musisz tylko podać typ rozpoczynanego projektu i jego nazwę, a system automatycznie utworzy odpowiednią strukturę katalogów, zaimportuje najczęściej używane interfejsy API oraz wygeneruje podstawowe pliki, takie jak web.xml, index.jsp itd. z odpowiednimi domyślnymi ustawieniami. Wszystko to jest możliwe dzięki ogólnie przyjętym konwencjom. Dzięki temu znacznie zmniejsza się ilość pracy do wykonania i decyzji do podjęcia przez programistę. Nie trzeba definiować konfiguracji, która jest uważana za konwencjonalną. Trzeba tylko określić to, co jest nietypowe. Efekty tego są bardzo znamienne. Wystarczy tylko kilka adnotacji do zwykłego obiektu, aby pozbyć się nieporęcznych deskryptorów wdrożenia XML i plików konfiguracyjnych aplikacji. Jak widać na listingu 2.1, wystarczą jedynie trzy adnotacje do zamiany zwykłego obiektu w singletonowe ziarno tworzone i inicjowane podczas urucham iania program u i zarządzane przez kontener. UWAGA Podejście polegające na przedkładaniu konwencji nad konfigurację nazywa się też kodowaniem według konwencji.
CDI W strzykiwanie zależności to wzorzec projektowy (zob. rozdział 5., „Wstrzykiwanie zależności i CDI”) rozłączający relacje występujące między kom ponentem i jego zależnościami. Odbywa się to przez wstrzykiwanie zależności do obiektu zamiast tworzyć je w obiekcie za pomocą słowa kluczowego new. Dzięki przeniesieniu obowiązku tworzenia zależności z obiektu na kontener m ożna wymieniać zależności między zgodnymi ze sobą obiektami podczas kompilacji i w czasie wykonywania programu. Ziarna zarządzane przez kontener nazywają się ziarnami zarządzanymi CDI (ang. Context and Dependency Injection). Ich egzemplarze są tworzone przy urucham ianiu kontenera. Wszystkie zwykłe obiekty mające domyślny konstruktor i nieutworzone przy użyciu słowa kluczowego new są ziarnami zarządzanymi CDI wstrzykiwanymi do obiektu na podstawie dopasowywania typów. Aby doszło do wstrzyknięcia, obiekt przyjmujący musi mieć zadeklarowane pole, konstruktor lub metodę z adnotacją @ Inject. Potem na podstawie typu zadeklarowanego obiektu określa się, którą zależność wstrzyknąć. Na listingu 2.2 przedstawiono zwykły obiekt mający domyślny konstruktor, a więc podlegający zarządzaniu jako ziarno CDI, a na listingu 2.3 pokazano sposób wstrzyknięcia zarządzanego ziarna. Kontener wie, które ziarno wstrzyknąć, dzięki jego typowi. Kontener zarządza tylko jednym ziarnem CDI typu Message, więc dokonuje wstrzyknięcia właśnie jego.
44
I
ROZDZIAŁ 2. Podstawy Javy EE
Listing 2.2. Przykład wstrzykiwania zależności — zależność package com .devchronicles.basicsofjavaee; public c la ss Message { public S tring getMessage() { return "W itaj, św iecie!" ; } } Listing 2.3. Przykład wstrzykiwania zależności — odbiorca package com .devchronicles.basicsofjavaee; import ja v a x .in je c t.I n je c t; public c la ss Service { @Inject p riv a te Message message; public void showMessage() { System .out.println(m essage.getM essage()); } } Dociekliwy czytelnik zapyta, co się stanie, jeśli kontener będzie zarządzał większą liczbą ziaren typu Message. Aby to było możliwe, Message musiałby być interfejsem mającym więcej niż jedną konkretną implementację. To bardzo ciekawy przypadek. Tego rodzaju niejednoznaczności można rozwiązywać na różne sposoby. Kilka z nich poznasz w dalszych rozdziałach tej książki, a jeśli zżera Cię ciekawość, przejdź od razu do rozdziału 5. Kontekst to cecha odróżniająca ziarna EJB od ziaren zarządzanych CDI. Ziarna CDI istnieją w pewnym kontekście, a EJB — nie. Ziarna CDI są tworzone w kontekście zakresu, istnieją do jego końca, po czym zostają zniszczone. W yróżnia się cztery zakresy oznaczane następującymi adnotacjami: @ ApplicationScope, @ ConversationScope, @SessionScope oraz @RequestScope. Kontener CDI kontroluje istnienie ziarna na podstawie zdefiniowanego m u zakresu. Na przykład ziarno z adnotacją @SessionScope istnieje przez okres istnienia sesji HTTP i na końcu tego zakresu zostaje zniszczone oraz zaznaczone do recyklingu. W odróżnieniu od ziaren CDI ziarna EJB nie mają zakresu, więc trzeba je samodzielnie usuwać przy użyciu metody z adnotacją @Remove.
Interceptory W większości aplikacji występują zagadnienia, które nie pasują dobrze do podstawowej logiki aplikacji, ale nie da się ich oddzielić od projektu lub implementacji aplikacji. Zagadnienia te są przekrojowe i mają wpływ na różne części aplikacji. Często są odpowiedzialne za powstawanie duplikatów kodu i współzależności, które osłabiają elastyczność systemu. Implementacja ich jako interceptorów pozwala na odłączenie ich od podstawowych zagadnień. Robi się to przez logiczne oddzielenie ich implementacji i przechwytywanie wywołań metod do rdzenia oraz wywoływanie odpowiednich metod. Interceptory implementuje się za pom ocą adnotacji @ In tercep to rs z nazwą klasy takiego przekrojowego zagadnienia. Na listingu 2.4 m etoda setV alues jest przechwytywana w momencie wywołania przez L o g g e rIn te rc e p to r. c la s s .
Podsumowanie
| 45
Listing 2.4. Rdzenna metoda przechwytywana przez interceptor dziennika @ Interceptors(L oggerInterceptor.class) public void setV alu es(In teg er value, S tring name) { th is .v a lu e = value; this.nam e = name; } Interceptor ten może używać param etrów przechwyconej metody i wykonać przekrojową logikę, aby następnie wrócić i w pełni wykonać przechwyconą metodę. Na listingu 2.5 interceptor dziennika używa param etrów metody setV alues i zapisuje je w dzienniku systemowym. Listing 2.5. Interceptor dziennika @AroundInvoke public logger(InvocationC ontext ic) throws Exception { O bject[] params = ic .g e tP a ra m e ters(); logger.w arning("Przekazane parametry: " + params); } Interceptory można definiować w kodzie biznesowym i w plikach deskryptorów wdrożenia. Ten i inne aspekty posługiwania się interceptoram i zostały opisane w rozdziale 8., „Programowanie aspektowe (interceptory)”.
Podsumowanie W tym rozdziale krótko przedstawiliśmy najważniejsze cechy Javy EE i historię stosowanych w niej zasad. Opisaliśmy prawidłową architekturę warstwową projektu Java EE i zaprezentowaliśmy długą listę specyfikacji JSR, aby pom óc Ci wybrać najlepszy kontener do Twojego projektu. Na końcu rozdziału wymieniliśmy najważniejsze zasady Javy EE polegające na przedkładaniu konwencji nad konfigurację oraz dodaliśmy kilka słów na temat CDI. W następnym rozdziale znajduje się opis pierwszego wzorca projektowego. Skupiamy się w nim na implementacji i konkretnych przykładach.
ĆWICZENIA 1.
Zaprojektuj aplikację bankową, którą masz zintegrować z głównym systemem zaplecza i w ramach której masz udostępnić usługi dla klientów sieciowych, mobilnych i macierzystych desktopowych.
2.
Wyobraź sobie implementację aplikacji sieciowej dla aplikacji zaprojektowanej w poprzednim punkcie. Która warstwa powinna zawierać aplikację sieciową?
3.
Po długich dyskusjach bank, w którym pracujesz, postanowił zrezygnować z systemu głównego i poprosił Cię o zaprojektowanie systemu zastępczego. Na które części projektu będzie to miało wpływ?
46
I
ROZDZIAŁ 2. Podstawy Javy EE
II Implementacja wzorców projektowych w Javie EE
^
Rozdział 3. W zorzec Fasada
^
Rozdział 4. W zorzec Singleton
^
Rozdział 5. W strzykiwanie zależności i CDI
^
Rozdział 6. W zorzec Fabryka
^
Rozdział 7. W zorzec Dekorator
^
Rozdział 8. Programowanie aspektowe (interceptory)
^
Rozdział 9. Asynchroniczność
^
Rozdział 10. Usługa odmierzania czasu
^
Rozdział 11. W zorzec Obserwator
^
Rozdział 12. W zorzec Dostęp do Danych
^
Rozdział 13. REST-owe usługi sieciowe
^
Rozdział 14. W zorzec Model - W idok - Kontroler
^
Rozdział 15. Inne wzorce projektowe w Javie EE
3 Wzorzec Fasada
ZAWARTOŚĆ ROZDZIAŁU:_______ > przeznaczenie wzorca Fasada; > krótki opis korzyści ze stosowania wzorca Fasada; > trzy sposoby implementacji wzorca: POJO, bezstanowe ziarno sesyjne i stanowe ziarno sesyjne; > różnice między stanowym i bezstanowym ziarnem sesyjnym; > kiedy i jak stosować ten wzorzec; > przestrogi dla użytkowników wzorca i potencjalne pułapki.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r03, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. W zorzec Fasada to jeden ze strukturalnych wzorców projektowych zawartych w książce Bandy Czworga1. Opisuje on metodę polegającą na zamknięciu skomplikowanej logiki biznesowej w interfejsie wyższego poziom u ułatwiającym korzystanie z podsystemu. W tym celu często grupuje się wywołania powiązanych ze sobą m etod i wywołuje się je po kolei z jednej metody.
1 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010.
50
I
ROZDZIAŁ 3. Wzorzec Fasada
Z szerszej perspektywy każdy interfejs API m ożna traktować jak implementację wzorca Fasada, ponieważ interfejs zapewnia prostą fasadę skrywającą skomplikowane mechanizmy. Każde wywołanie metody z interfejsu API powoduje wywołanie wielu innych metod z ukrytego za nim podsystemu. Przykładem fasady jest interfejs j a v a x . s e r v l e t .h ttp .H ttp S e s s io n . Ukrywa on skomplikowaną logikę dotyczącą obsługi sesji i udostępnia tylko parę łatwych w użyciu metod.
Czym jest Fasada W książce Bandy Czworga znajduje się taki opis tego wzorca: „zapewnia jednolity interfejs do zestawu interfejsów w podsystemie”. W książce Wzorce projektowe. Rusz głową!2 podano takie samo wyjaśnienie oraz zaznaczono, że choć wzorzec Fasada ukrywa złożoność podsystemu, to jednocześnie zapewnia szansę korzystania z wszystkich możliwości podsystemu przez łatwy w obsłudze interfejs. Prostym przykładem zastosowania wzorca Fasada w realnym świecie może być pralka mająca tylko dwa tryby prania — do ubrań bardzo brudnych i do ubrań tylko trochę brudnych. W każdym z tych trybów maszyna wykonuje wiele z góry ustalonych czynności: ustawia tem peraturę wody, podgrzewa wodę, ustawia czas prania, ustawia czas wirowania, dodaje proszek, dodaje wybielacz, dodaje zmiękczacz tkanin itd. Każdy tryb m a inny zestaw instrukcji (różne ilości środka piorącego, wyższa lub niższa tem peratura wody, dłuższy lub krótszy czas wirowania itd.). Ten prosty interfejs zapewnia dwa program y prania, za którymi kryją się skomplikowana logika wybierania tem peratury wody, czasu wirowania, cyklu prania oraz różne metody dotyczące dodawania detergentu, wybielacza i zmiękczacza tkanin. Użytkownika pralki nie interesują te złożone kwestie, a jego jedynym zadaniem jest określenie, czy ubrania są bardzo, czy tylko trochę brudne. Zasadniczo jest to więc przykład zastosowania wzorca projektowego Fasada w projekcie pralki. W dalszej części rozdziału przedstawiamy implementację tego przypadku. W zorzec Fasada najczęściej implementuje się w następujących celach i sytuacjach: ^
W celu dostarczenia prostego i jednolitego m echanizmu dostępu do starego systemu zaplecza.
^
W celu utworzenia publicznego interfejsu API do klas, np. sterownika.
^
Aby dać dostęp do usług. Usługi są kombinacjami, jak w przykładzie pralki.
^
Aby zredukować liczbę wywołań sieciowych. Fasada wysyła wiele wywołań do podsystemu, ale zdalny klient wykonuje tylko jedno wywołanie w fasadzie.
^
W celu zamknięcia przepływu i wewnętrznych szczegółów aplikacji dla bezpieczeństwa i uproszczenia. UWAGA Fasady czasami implementuje się jako singletonowe abstrakcyjne fabryki.
2 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010.
Czym jest Fasada
OPOWIEŚĆ WOJENNA Dawno, dawno temu, w początkach technologii J2EE, pracowałem jako młodszy programista nad gigantyczną aplikacją bankową, w której implementowaliśmy prawie wszystkie wzorce projektowe J2EE. Wszystkie ziarna EJB były opakowane przez fasadę, a każde ziarno EJB usługi wykorzystujące tę fasadę było opakowane przez inną fasadę. Mieliśmy też interfejsy dla fasad, aby mieć pewność, że nie uszkodzimy API. W J2EE ziarno EJB potrzebuje lokalnego i zdalnego interfejsu, więc napisanie jednego ziarna EJB pociągało za sobą konieczność napisania dodatkowych czterech interfejsów i dwóch klas. Nasz kod nie przypominał spaghetti, ale warstw miał więcej niż lazania. W swoim małym światku byliśmy z siebie całkiem zadowoleni, ale tylko do czasu, gdy inne zespoły zaczęły korzystać z naszego produktu. Bardzo szybko wystąpiły problemy z wydajnością systemu i realizacją próśb o wprowadzenie zmian. Wynajęliśmy od jednego z naszych dostawców serwerów słynnego i drogiego konsultanta, aby przeanalizował te problemy. Konsultant przeprowadził parę rozmów, poszperał w naszym kodzie źródłowym i doszedł do wniosku, że trzeba trochę pozmieniać, po czym usunął wszystkie fasady i związane z nimi interfejsy. Ku zadowoleniu wszystkich efektem tych działań było zmniejszenie ilości kodu do obsługiwania i znaczny wzrost wydajności programu. Morał z tej historii jest taki, że wzorców projektowych — nawet tych najprostszych — należy używać oszczędnie i tylko wtedy, gdy jest to naprawdę uzasadnione, a na pewno nie po to, by pochwalić się ich znajomością.
Diagram klas wzorca Fasady Jak widać na diagramie klas przedstawionym na rysunku 3.1, wzorzec Fasada zapewnia prosty interfejs do pewnego systemu. Opakowuje skomplikowaną drobiazgową logikę.
Rysunek 3.1. Diagram klas wzorca projektowego Fasada
| 51
52
| ROZDZIAŁ 3. Wzorzec Fasada
Implementacja wzorca Fasada w zwykłym kodzie źródłowym Implementacja wzorca Fasada nie jest trudna. Nie trzeba trzymać się żadnej ścisłej struktury czy przestrzegać jakiegoś restrykcyjnego zestawu reguł. Jako implementację Fasady m ożna traktować każdą metodę zapewniającą dostęp do jakiegoś skomplikowanego mechanizmu. Na listingu 3.1 przedstawiona jest implementacja opisanego na początku rozdziału przykładu z pralką. Potrzebne są dwie m etody — h e a v ily S o ile d i lig h tly S o ile d reprezentujące dwa programy prania (odpowiednio dla mocno i lekko zabrudzonych ubrań). Wszystkie skomplikowane operacje (wybór tem peratury wody, czas wirowania, podjęcie decyzji, czy dodać wybielacz itd.) są wykonywane w metodach wywoływanych wewnątrz fasady. Listing 3.1. Implementacja przykładu porównującego Fasadę do pralki public c la ss WashingMachine { public void heavilyS oiled() { setW aterTemperature(100); setWashCycleDuration(90); setSpinCycleD uration(10); addD etergent(); addBleach(); addF abricS oftener(); heatW ater(); startW ash(); } public void lig h tly S o ile d () { setW aterTemperature(40); setWashCycleDuration(20); setSpinCycleD uration(10); addD etergent(); heatW ater(); startW ash(); } } / / aby użyć fa sa d y
new W ashingM achine().lightlySoiled() ; Jeśli chcesz skorzystać z tej funkcjonalności, wywołaj metodę fasady heavilySoiled lub lig h tly S o ile d , a ta wykona za Ciebie wszystkie skomplikowane czynności związane z praniem ubrań. Cała złożona logika jest ukryta za fasadą i dostępna tylko za pośrednictwem tych dwóch jej metod. Implementacja metod nie jest połączona z klientem, dzięki czemu można ją zmienić bez modyfikowania sposobu użycia przez niego usług pralki. Klient nic nie wie o implementacji tych metod i w ogóle go to nie interesuje. Dla niego liczy się tylko możliwość skorzystania z pewnej usługi. Niniejszy przykład dem onstruje jedną z wielu korzyści płynących z używania wzorca Fasada. W tej książce nie opisujemy wszystkich zalet, ale poniżej przedstawiamy krótką listę najważniejszych z nich: ^
redukcja wzajemnych powiązań elementów program u, ponieważ klient nic nie wie o podsystemie;
^
ułatwiona obsługa i łatwiejsze panowanie nad kodem przy wprowadzaniu zmian;
Implementacja wzorca Fasada w Javie EE | 53
^
możliwość wielokrotnego wykorzystania funkcjonalności dzięki wielokrotnemu wykorzystaniu kontroli i szczegółowej logiki;
^
spójność wykonywania usługi uzyskiwana przez każdorazowo jednakowe wywoływanie tej samej metody;
^
redukcja złożoności logiki biznesowej przez zgrupowanie powiązanych ze sobą metod i wywoływanie ich z jednej metody;
^
centralizacja zabezpieczeń i zarządzania transakcjami;
^
możliwość testowania i tworzenia atrap implementacji wzorca. UWAGA Implementacja ta może być nazywana fasadą POJO w celu odróżnienia od stanowych i bezstanowych implementacji przedstawionych w dalszej części tego rozdziału.
Implementacja wzorca Fasada w Javie EE W odróżnieniu od wielu innych wzorców opisanych w tej książce ta metoda nie m a wbudowanej implementacji w Javie EE. M ożna to łatwo nadrobić przy użyciu stanowych lub bezstanowych ziaren EJB. Zastosowanie EJB m a tę zaletę, że ułatwia dostęp do innych ziaren EJB, które mogą być wymagane przez fasadę.
Fasada z ziarnami bezstanowymi Aby zademonstrować tę implementację, przyjmujemy założenie, że masz trzy ziarna EJB pokazane na listingu 3.2 o różnej, choć spokrewnionej funkcjonalności: C ustom erService, LoanService oraz A ccountService. Listing 3.2. Kod trzech ziaren EJB tworzących podsystem dla fasady package com .devchronicles.facade; import ja v a x .e jb .S ta te le s s ; @ Stateless public c la ss CustomerService { public long getCustom er(int sessionID) { / / pobranie identyfikatora zalogowanego klienta
return 100005L; } public boolean checkId(long x) { / / spraw dzenie popraw ności identyfikatora klienta
return tru e ; } } package com .devchronicles.facade; import ja v a x .e jb .S ta te le s s ; @ Stateless public c la ss LoanService {
54
| ROZDZIAŁ 3. Wzorzec Fasada
public boolean checkCreditRating(long id , double amount) { / / sprawdzenie, czy klient m oże podjąć taką kw otę
return tru e ; } } package com .devchronicles.facade; import ja v a x .e jb .S ta te le s s ; @ Stateless public c la ss AccountService { public boolean getLoan(double amount) { / / sprawdzenie, czy w skarbcu b a n k u je s t wystarczająca ilość środków
return tru e ; } public boolean setCustomerBalance(long id , double amount) { / / ustaw ienie nowego salda klienta
return tru e ; } } Ziarna te m ożna zebrać w logiczną kolekcję powiązanych elementów funkcjonalności, aby utworzyć implementację wzorca Fasada, jak pokazano na listingu 3.3. Listing 3.3. Implementacja bezstanowej fasady package com .devchronicles.facade; import ja v a x .e jb .S ta te le s s ; import ja v a x .in je c t.I n je c t; @ Stateless public c la ss BankServiceFacade { @Inj ect CustomerService customerService; @Inj ect LoanService loanService; @Inj ect AccountService accountService; public boolean getLoan(int sessio n Id , double amount) { boolean re s u lt = fa ls e ; long id = custom erService.getC ustom er(sessionId); i f (custom erService.checkId(id)) { i f (loanService.checkC reditR ating(id, amount)) { i f (accountService.getLoan(amount)) { re s u lt = accountService.setC ustom erB alance(id, amount); } } } return re s u lt; } }
Gdzie i kiedy używać wzorca Fasada
| 55
Jedna fasada może wywoływać inne fasady z innych podsystemów, które to fasady zawierają własne elementy logiki i przepływu sterowania. Na tym właśnie polega jedna z zalet fasad — uproszczona hierarchia wywołań metod. Każdy podsystem m a jedną fasadę i do komunikacji tych podsystemów używa się tych właśnie fasad.
Fasada ze stanowym ziarnem To samo ziarno m ożna zaimplementować jako stanowe ziarno sesyjne, a nawet singletonowe, jeśli ukryje się część skomplikowanej logiki i udostępni klientowi łatwy w obsłudze interfejs. Jedyną zm ianą jest dodatek adnotacji @ S tateful, która oznaczy ziarno EJB jako stanowe. W J2EE (przed 5.0) zalecano stosowanie wzorca Fasada do im plem entow ania wzorca fasady sesyjnej. Ale nawet w uproszczonej metodyce Javy EE fasady nadal są przydatne do kontrolowania i hermetyzowania przepływu pracy.
Gdzie i kiedy używać wzorca Fasada W zorca Fasada należy używać do hermetyzowania skomplikowanej logiki (biznesowej) na wysokim poziomie i w celu zapewnienia łatwego w obsłudze punktu dostępowego w postaci interfejsu API. Jeśli kiedykolwiek ktoś zleci Ci utworzenie interfejsu albo API, to najpierw pomyśl o złożoności logiki i o tym, co może się zmienić. Wzorzec Fasada to świetna metoda na zapewnienie prostego API i ukrycie tych części podsystemu, które mogą ulec zmianie. Z drugiej strony, zamykanie m etod w fasadach bez wyraźnej potrzeby jest oznaką złego stylu programowania i tylko dodaje niepotrzebne warstwy do program u. Zbyt wczesna hermetyzacja może spowodować powstanie nadm iernej liczby niczego niewnoszących wywołań i warstw. Przy im plem entowaniu fasady sesyjnej należy się upewnić, czy w danym przypadku w ogóle trzeba przechowywać inform acje o stanie. Jeśli trzeba wywoływać tylko jedną metodę fasady w celu skorzystania z usługi, to nie ma tu mowy o komunikacji dwustronnej, nie ma więc też potrzeby zapisywania konwersacyjnego stanu między kolejnymi wywołaniami metody. Taką fasadę lepiej jest zaimplementować jako bezstanowe ziarno sesyjne. Z drugiej strony, jeżeli między wywołaniami metody musi być przechowywany stan konwersacyjny, najlepszym sposobem implementacji fasady jest użycie stanowego ziarna sesyjnego. Z wykorzystywaniem stanowych fasad sesyjnych trzeba uważać, ponieważ wiążą one zasoby serwera, aż klient je zwolni albo upłynie określona ilość czasu. W efekcie może stać się tak, że stanowa fasada będzie nieużywana przez większość czasu powiązania z klientem. Jej jedyną rolą będzie przechowywanie stanu i zużywanie zasobów. Ponadto, w odróżnieniu od bezstanowych fasad sesyjnych, fasady stanowej nie można wykorzystywać wielokrotnie i współdzielić z innymi klientami, ponieważ każde żądanie tworzy nowy egzemplarz fasady stanowej przechowującej stan dla sesji danego klienta. Dlatego zawsze dobrze się zastanów, zanim zastosujesz ten wzorzec. Dokładnie przeanalizuj przypadek i podejmij odpowiednią decyzję.
56
| ROZDZIAŁ 3. Wzorzec Fasada
Podsumowanie W zorzec Fasada m ożna zaimplementować jako zwykły obiekt, bezstanowe ziarno sesyjne oraz stanowe ziarno sesyjne. Różne sposoby implementacji tego wzorca służą do rozwiązywania różnych problemów, ale większość z nich trzyma się podstawowego celu — zapewnienie wysokopoziomowego prostego interfejsu do bardziej skomplikowanego podsystemu. Implem entując fasadę jako stanowe ziarno sesyjne, dopilnuj, aby nie sprawiała kłopotów z poziomem wykorzystania zasobów. Dobrze zaprojektow ana aplikacja popraw nie wykorzystuje wzorzec Fasada do hermetyzacji skomplikowanej logiki i w celu odłączenia podsystemów od klientów. Zbyt wczesne lub nadm ierne stosowanie tego wzorca może jednak doprowadzić do skomplikowania systemu przez utworzenie wielu warstw. Wzorzec fasady sesyjnej jest podobny do granicy we wzorcu architekturalnym Jednostka - Sterowanie - Granica (ang. entity-control-boundary) i jest spokrewniony z wzorcami Adapter i Opakowanie (ang. wrapper).
ĆWICZENIA 1.
Wymień kilka implementacji w publicznych API wzorca Fasada i wyjaśnij, jak w nich ukryto skomplikowaną logikę podsystemu.
2.
Napisz fasadę ukrywającą skomplikowaną logikę systemu do obsługi zamówień i płatności.
3.
Zamknij wywołania metod z tych dwóch podsystemów — płatności i zamówienia — w tylko dwóch metodach.
4.
Utwórz fasadę jako singleton.
4 Wzorzec Singleton
ZAWARTOŚĆ ROZDZIAŁU: > różne sposoby implementacji wzorca Singleton oraz jego zastosowania i typowe błędy popełniane przez programistów; > problemy powodowane przez wykorzystanie statycznych składowych i metod w środowiskach wielowątkowych; > korzyści z wprowadzenia w Javie SE 5 typu wyliczeniowego i sposoby jego wykorzystania do tworzenia bezpiecznych wątkowo singletonów; > sposoby użycia adnotacji @Singleton w Javie EE i jej radykalny wpływ na zmianę sposobu implementacji wzorca Singleton w ziarnach sesyjnych; > zastosowanie technik współbieżności zarządzanej przez ziarno i kontener oraz kontrolowanie dostępu do metod biznesowych przy użyciu adnotacji @LockType; > największe wady wzorca Singleton i powód, dla którego popadł on w niełaskę programistów, zostając okrzyknięty antywzorcem.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r04, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału.
58
I
ROZDZIAŁ 4. Wzorzec Singleton
W zorzec Singleton to jeden z najłatwiejszych i najlepiej znanych wzorców projektowych, który jednak wyszedł z mody. Niektórzy uważają go wręcz za antywzorzec, o czym szerzej piszemy w dalszej części rozdziału. Mimo to w wielu systemach szkieletowych, jak chociażby Spring, wzorzec ten jest wykorzystywany na potęgę, a w Javie EE znajduje się jego elegancka i łatwa w obsłudze gotowa implementacja. Z tego rozdziału dowiesz się, do czego służą singletony, dlaczego popadły w niełaskę programistów, jak m ożna je wykorzystać w aplikacjach w Javie EE i jak się je implementuje. Wzorzec Singleton w książce Bandy Czworga1 został zaliczony do wzorców kreacyjnych i opisuje technikę polegającą na tworzeniu tylko jednego egzemplarza określonego typu. Obecność tylko jednego obiektu danego typu w systemie może być korzystna pod wieloma względami, np. przy dostępie globalnym albo gdy buforuje się cenne zasoby. Ale w środowiskach wielowątkowych stosowanie singletonów powoduje ryzyko wystąpienia wyścigów do danych. Większość języków program owania nie m a wbudowanych mechanizmów do tworzenia singletonów, więc programiści zazwyczaj muszą tworzyć własne implementacje. W Javie EE jest taki mechanizm. Przy jego użyciu program ista może łatwo utworzyć singleton przez dodanie do klasy specjalnej adnotacji.
Czym jest Singleton W książce Bandy Czworga wzorzec Singleton opisano w następujący sposób: „pozwala na utworzenie tylko jednego egzemplarza klasy i zapewnia do niego globalny punkt dostępu”. Podobne objaśnienie znajdujemy w książce Wzorce projektowe. Rusz głową!2. Singletonów często używa się w połączeniu z fabrykami (opisanymi w rozdziale 6., „Wzorzec Fabryka”). Oto lista najczęstszych zastosowań wzorca Singleton: ^
W celu zapewnienia dostępu do wspólnych danych w całej aplikacji, np. do danych konfiguracyjnych.
^
W celu ładowania i buforowania cennych zasobów tylko raz oraz zapewniania globalnego dostępu dla wszystkich i zoptymalizowania wydajności.
^
Do utworzenia egzemplarza rejestratora dziennikowego aplikacji, ponieważ zazwyczaj potrzebny jest tylko jeden.
^
Do zarządzania obiektami w klasie implementującej wzorzec Fabryka.
^
Do utworzenia obiektu fasady, ponieważ zazwyczaj potrzebny jest tylko jeden.
^
Do leniwego tworzenia statycznych klas, ponieważ obiekty singletonowe można tworzyć leniwie.
W systemie Spring singletony są wykorzystywane przy tworzeniu ziaren (domyślnie ziarna Springa są singletonami), a w Javie EE są one używane wewnętrznie, np. w lokalizatorze usług. W Javie SE zastosowanie wzorca Singleton m ożna zaobserwować w implementacji klasy runtime. Wynika z tego, że singletony są przydatne, tylko trzeba umieć się nim i posługiwać. Z drugiej strony, nadużywanie wzorca Singleton może powodować nadm ierne zużywanie zasobów buforowych i uniemożliwiać systemowi recyklingu pamięci odzyskiwanie pamięci po obiektach oraz zwalnianie cennych zasobów pamięciowych. Ponadto może ono uniemożliwić wykorzystanie
1 Erich G am m a, R ichard H elm , Ralph Johnson, John V lissides, Wzorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego u żytku, H elion, 2010. 2 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010.
Czym jest Singleton
| 59
zalet tworzenia obiektów i dziedziczenia. Nadzwyczajna liczba singletonów zazwyczaj świadczy o tym, że system obiektowy został źle zaprojektowany i mogą w nim występować problemy z wydajnością i wykorzystaniem pamięci. Ponadto singletony mogą przeszkadzać w testowaniu jednostkowym. Więcej informacji na tem at potencjalnych problemów, jakie mogą nękać programistę stosującego wzorzec Singleton, znajduje się w dalszej części rozdziału.
Diagram klas wzorca Singleton Z diagramu klas przedstawionego na rysunku 4.1 m ożna wywnioskować, że implementacja wzorca Singleton składa się z jednej klasy zawierającej odniesienie do jedynego swojego egzemplarza oraz kontrolującej jego tworzenie i wykorzystanie przez jedną metodę dostępową.
+ getlnstance (): Singleton Rysunek 4.1. Diagram klas wzorca Singleton
Implementacja wzorca Singleton w zwykłym kodzie Singleton zapewnia tylko jeden obiekt danego typu, więc pierwszą czynnością powinno być przejęcie kontroli nad tworzeniem obiektów klasy. Jest to bardzo łatwe, ponieważ wystarczy w tym celu tylko ukryć konstruktor przed światem zewnętrznym. package com .devchronicles.singleton; public c la ss MySingleton { p riv a te MySingleton() { II im plem entacja
} } Następnie należy zdefiniować metodę tworzącą jedyny egzemplarz lub zwracającą go, jeśli został już utworzony. Ponieważ egzemplarz klasy MySingleton początkowo nie istnieje, tworząca go m etoda musi być statyczna, aby m ożna ją było wywoływać przy użyciu nazwy klasy, np. M y S in g le to n .g e tIn s ta n c e (). W miejscu kom entarza num er 1 na listingu 4.1 znajduje się kod sprawdzający, czy singleton już istnieje, i tworzący go w razie negatywnego wyniku testu. Jeśli natom iast test wypadnie pozytywnie, zamiast tworzyć nowy obiekt, zwracamy ten, który został utworzony w poprzednim wywołaniu m etody g e tI n s ta n c e ( ) . Każde kolejne wywołanie tej m etody pow inno mieć taki sam skutek w postaci zwrócenia wcześniej utworzonego egzemplarza obiektu klasy MySingleton. Ten kod może się wydawać poprawny, ale w rzeczywistości nie jest ani poprawny, ani kompletny. Jako że metoda tworząca obiekt nie jest atomowa, może sprawiać kłopoty związane z wyścigami do danych — w środowiskach wielowątkowych może się zdarzyć, że zostanie utworzony więcej niż jeden egzemplarz tego singletonu.
60
I
ROZDZIAŁ 4. Wzorzec Singleton
Listing 4.1. Prosta implementacja wzorca Singleton
package com .devchronicles.sin g leto n ; public c la ss MySingleton1 { p riv a te s t a t i c MySingleton1 in stan ce; p riv a te MySingleton1() { } public s t a ti c MySingleton1 g e tIn sta n c e () { i f (in stan ce == n u ll) { // 1 in stan ce = new MySingleton1(); } return in stan ce; } } Rozwiązaniem problem u z wyścigiem jest założenie blokady na czas tworzenia egzemplarza i zwolnienie jej dopiero po zwróceniu obiektu. W Javie mechanizm blokowania można implementować przy użyciu słowa kluczowego synchronized — listing 4.2. Listing 4.2. Synchronizacja singletonu w celu zapewnienia bezpieczeństwa wątkowego package com .devchronicles.sin g leto n ; public c la ss MySingleton { p riv a te s ta t i c MySingleton instance; p riv a te M ySingleton() { } public s t a t i c synchronized MySingleton g etIn stance() { i f (in stan ce == n u ll) { in stan ce = new MySingleton(); } return in stan ce; } } Egzemplarz singletonowy m ożna również utworzyć podczas ładowania klasy, jak pokazano na listingu 4.3. Likwiduje to potrzebę synchronizowania operacji tworzenia singletonowego egzemplarza i powoduje utworzenie tego obiektu po załadowaniu przez maszynę wirtualną Javy wszystkich klas (i zanim klasa mogłaby wywołać metodę g e tIn s ta n c e () ). Jest to możliwe dzięki temu, że statyczne składowe i bloki są wykonywane podczas ładowania klas. Listing 4.3. Tworzenie obiektu singletonowego podczas ładowania klasy package com .devchronicles.sin g leto n ; public c la ss MySingleton { p riv a te f in a l s t a t i c MySingleton in stan ce = new MySingleton(); p riv a te MySingleton() {
Czym jest Singleton
I 61
} public s t a ti c MySingleton g e tIn sta n c e () { return in stan ce; } } Inną możliwością jest wykorzystanie statycznego bloku, jak pokazano na listingu 4.4. Spowoduje to jednak leniwą inicjację, ponieważ blok statyczny jest wywoływany przed konstruktorem. Listing 4.4. Tworzenie obiektu singletonowego w bloku statycznym package com .devchronicles.singleton; public c la ss MySingleton { p riv a te s t a t i c MySingleton in stan ce = n u ll; s ta t i c { instan ce = new MySingleton(); } p riv a te M ySingleton() { } public s t a ti c MySingleton g e tIn sta n c e () { return in stan ce; } } Do popularnych technik tworzenia singletonów należy też podwójnie sprawdzane blokowanie. M etoda ta jest uważana za bezpieczniejszą od pozostałych, ponieważ sprawdza egzemplarz singletonu pierwszy raz przed założeniem blokady na klasę singletonową i drugi raz przed utworzeniem obiektu. Implementację tej techniki przedstawiono na listingu 4.5. Listing 4.5. Implementacja blokowania z podwójnym sprawdzaniem package com .devchronicles.sin g leto n ; public c la ss MySingleton { p riv a te v o la tile MySingleton instance; p riv a te MySingleton() { } public MySingleton g etIn stan ce() { i f (in stan ce == n u ll) i II 1 synchronized (M ySingleton.class) i i f (in stan ce == n u ll) i II 2 instan ce = new MySingleton();
return in stan ce; } }
62
I
ROZDZIAŁ 4. Wzorzec Singleton
Zanim m etoda g e tIn s ta n c e () utworzy i przypisze do zmiennej egzemplarz klasy MySingleton, dwa razy sprawdza (pierwszy raz w miejscu kom entarza num er 1 i drugi raz w miejscu kom entarza num er 2), czy pryw atna składowa M ySingleton m a wartość n u ll. Mimo to żadna z przedstawionych technik nie jest absolutnie bezpieczna. Na przykład API Java Reflection umożliwia zmienianie modyfikatorów dostępu konstruktora na publiczne, czego efektem jest uzyskanie możliwości tworzenia większej liczby singletonów. Najlepszym sposobem na tworzenie singletonów w Javie jest wykorzystanie typu wyliczeniowego wprowadzonego w Javie 5, jak pokazano na listingu 4.6. Metodę tę gorąco poleca Joshua Bloch w swojej książce Java. Efektywne programowanie3. Typy wyliczeniowe z natury są singletonowe, więc większość pracy potrzebnej do utworzenia singletonu przejmuje od nas maszyna wirtualna Javy. W związku z tym uwalniamy się od konieczności stosowania synchronizowania operacji tworzenia i dostarczania obiektu oraz eliminujemy kłopoty związane z inicjacją. Listing 4.6. Implementacja wzorca Singleton przy użyciu typu wyliczeniowego package com .devchronicles.singleton; public enum MySingletonEnum { INSTANCE; public void doSom ethinglnteresting() { } } W tym przykładzie referencję do egzemplarza obiektu singletonowego pobiera się w następujący sposób: MySingletonEnum mse = MySingletonEnum.INSTANCE; Mając referencję do singletonu, można wywoływać jego metody, np. m se.doSom ethingInteresting();.
OPOWIADANIE WOJENNE Kilka lat temu jeden z moich znajomych, właściciel niewielkiej firmy programistycznej, poprosił mnie o pomoc w przeprowadzeniu rozmowy kwalifikacyjnej z kandydatem do pracy. Jako że zawsze lubiłem spotkania z innymi inżynierami, bez wahania się zgodziłem, aby nie przepuścić takiej okazji. Kandydat miał tylko kilka lat doświadczenia zawodowego, ale mógł pochwalić się dyplomem dobrej uczelni i z pewnością był bystry. Odbyliśmy długą rozmowę na temat Javy, JPA, Springa i innych znanych systemów szkieletowych Javy. Mój rozmówca był głodny wiedzy i bez problemów odpowiadał na zadawane przeze mnie pytania. Rozmowa kwalifikacyjna trwała ok. godziny, ale konwersowaliśmy sobie jeszcze trochę prywatnie. Spytałem go, co ostatnio czytał, a on powiedział, że książkę Wzorce projektowe. Rusz głową! Zaciekawiłem się, który z wzorców najbardziej przypadł mu do gustu albo o którym chciałby porozmawiać. Oczywiście wybrał Singleton. To wzbudziło we mnie podejrzenia. Programista ten uważał, że Singleton jest prosty i łatwy w implementacji, więc jego wybór był bezpieczny. Ale się przeliczył. Gdyby wybrał jakiś inny wzorzec, np. Dekorator, nie miałbym możliwości zagłębić się w bardziej zaawansowane kwestie tego pozornie prostego wzorca.
3 Joshua Bloch, Java. E fektyw ne program ow anie, wyd. 2, H elion, 2009.
Implementacja wzorca Singleton w Javie EE
| 63
Potem spytałem go, jak zaimplementowałby Singleton. Powiedział, że użyłby klasycznej prywatnej metody konstrukcyjnej, co oznaczało, że na pewno nie czytał książki Java. Efektywne programowanie i nigdy nie słyszał o implementacji opartej na wyliczeniu. Potem zadałem mu takie pytanie: „A co by było, gdybym za pomocą refleksji przywrócił publiczny poziom dostępu do konstruktora?". Nie potrafił ukryć zaskoczenia, ale w jego oczach widziałem, że planował to sprawdzić po powrocie do domu. Nie udało mu się znaleźć rozwiązania, ale nie powiedział też żadnej bzdury. Ciągle tylko rozmyślał nad tym pomysłem z refleksją. Kandydat ten może i nie znał poprawnej odpowiedzi, ale wykazał pasję i wielką chęć do uczenia się. Dostał tę posadę i został jednym z najlepszych programistów, z jakimi przyszło mi kiedykolwiek pracować.
Implementacja wzorca Singleton w Javie EE Wszystkie poprzednie przykłady kodu ilustrują techniki im plem entacji wzorca Singleton w standardowej Javie. Choć m ożna używać ich też w Javie EE, w tej technologii istnieje elegantsze i prostsze rozwiązanie — ziarna singletonowe.
Ziarna singletonowe W rozdziale 2., „Podstawy Javy EE”, pokazaliśmy sposób użycia stanowych i bezstanowych ziaren sesyjnych poprzez wykorzystanie prostych adnotacji. Podobne podejście m ożna zastosować do tworzenia singletonów. Aby zamienić klasę w ziarno singletonowe, wystarczy dodać do niej adnotację @ Singleton, jak pokazano na listingu 4.7. Listing 4.7. Implementacja wzorca Singleton przy użyciu adnotacji @Singleton package com .devchronicles.singleton; import import import import import
java.util.H ashM ap; jav a.u til.M ap ; javax.annotation.P ostC onst r u c t; jav a x .e jb .S in g le to n ; jav a.u til.lo g g in g .L o g g e r;
@Singleton public c la ss CacheSingletonBean8 { p riv a te Map myCache; @PostConstruct public void s t a r t () { Logger.getLogger("MyGlobalLogger").in fo ("D ziałam !"); myCache = new HashMap (); } public void addU ser(Integer id , S tring name) { myCache.put(id, name); }
64
I
ROZDZIAŁ 4. Wzorzec Singleton
public S tring getName(Integer id ) { return myCache.get(id); } } Dzięki wykorzystywaniu adnotacji w Javie EE nie trzeba używać konfiguracyjnych plików XML. W projekcie może znaleźć się plik bean.xml, ale w większości przypadków jest on pusty. Czasami jest tylko wykorzystywany do uruchamiania kontenera CDI (ang. Context and Dependency Injection). Adnotacja @ Singleton oznacza klasę jako singletonowe ziarno EJB, a kontener obsługuje tworzenie i wykorzystywanie jej jedynego egzemplarza. Jeśli uruchom isz ten kod na swoim serwerze, nie zobaczysz danych dziennika z singletonu, ponieważ nie wywołano metody oznaczonej adnotacją @ PostConstruct. Dlaczego?
Wykorzystywanie singletonów przy uruchamianiu Singletony w Javie EE domyślnie są inicjowane leniwie. W większości przypadków jest to dobre rozwiązanie — egzemplarz jest tworzony za pierwszym razem, gdy jest potrzebny. Ale czasami lepiej utworzyć go przy uruchamianiu programu, aby zapewnić błyskawiczny dostęp do singletonu. Jest to szczególnie ważne, gdy utworzenie egzemplarza jest czasochłonne albo wiadomo, że będzie potrzebny od samego początku działania aplikacji. Aby zapewnić utworzenie egzemplarza przy urucham ianiu program u, należy dodać do klasy adnotację @Sta rtu p , jak pokazano na listingu 4.8. Listing 4.8. Wywoływanie singletonu na początku działania programu package com .devchronicles.singleton; import import import import import import
java.util.H ashM ap; jav a.u til.M ap ; javax.annotation.P ostC onst r u c t; jav a x .e jb .S in g le to n ; ja v a x .e jb .S ta rtu p ; jav a.u til.lo g g in g .L o g g e r;
@Startup @Singleton public c la ss CacheSingletonBean9 { p riv a te Map myCache; @PostConstruct public void s t a r t () { Logger.getLogger("M yGlobalLogger").info("Dziaiam!"); myCache = new HashMap (); } public void addU ser(Integer id , S tring name) { myCache.put(id, name); } public S tring getName(Integer id) { return myCache.get(id); } }
Implementacja wzorca Singleton w Javie EE
| 65
Jeśli wyłączysz i włączysz serwer, nastąpi wywołanie metody postkonstrukcyjnej, ponieważ teraz singleton jest tworzony przy urucham ianiu serwera. Teraz rejestrator powinien otrzymać kom unikat Działam!
Określanie kolejności uruchamiania Powstaje kolejne pytanie. A co, jeśli utworzony singleton zależy od innego zasobu? Jak zaczekać na to, aż zasób ten stanie się gotowy? Choć może się wydawać, że to rzadki przypadek brzegowy, w istocie taki nie jest. Wyobraź sobie singleton ładujący i buforujący jakieś wiadomości z bazy danych. Może się to wydawać banalnie łatwe, ale nawet prosty odczyt z bazy danych może zależeć od innych usług. Co by było, gdyby pulę połączeń tworzył inny singleton albo, jeszcze lepiej, co by było, gdyby rejestracja danych w dzienniku zależała od innego singletonu? W Javie EE rozwiązaniem tego problemu jest specjalna adnotacja @DependsOn, której przekazuje się nazwę klasy, od której z kolei zależy nasza klasa (listing 4.9). W ten sposób m ożna łatwo określić kolejność urucham iania singletonów. Listing 4.9. Określanie kolejności uruchamiania za pomocą adnotacji @DependsOn package com .devchronicles.singleton; import import import import import import import
java.util.H ashM ap; jav a.u til.M ap ; javax.annotation.P ostC onst r u c t; javax.ejb.ConcurrencyManagement; javax.ejb.ConcurrencyManagementType; javax.ejb.DependsOn; javax.ejb.EJB ;
@Startup @DependsOn("MyLoggingBean") @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) @Singleton public c la ss CacheSingletonBean12 { p riv a te Map myCache; @EJB MyLoggingBean loggingBean; @PostConstruct public void s t a r t () { loggingBean.logInfo("D ziaIam !"); myCache = new HashMap (); } @Lock(LockType.WRITE) public void addU ser(Integer id , S tring name) { myCache.put(id, name); } @Lock(LockType.READ) public S tring getName(Integer id) { return myCache.get(id); } }
66
I
ROZDZIAŁ 4. Wzorzec Singleton
Teraz utworzymy jeszcze jeden singleton (listing 4.10), do którego odnosi się powyższy singleton. Listing 4.10. Określanie kolejności uruchamiania package com .devchronicles.sin g leto n ; import import import import
jav ax .annotation.PostC onst r u c t; jav a x .e jb .S in g le to n ; ja v a x .e jb .S ta rtu p ; jav a.u til.lo g g in g .L o g g e r;
@Startup @Singleton public c la ss MyLoggingBean { p riv a te Logger logger; @PostConst ruct public void s t a r t ( ) { logger = Logger.getLogger("MyGlobalLogger" ) ; lo g g er.in fo ("Jestem pierw szy !!!"); } public void lo g In fo (S trin g msg) { logger.info(m sg); } } Tu również m ożna wykorzystać adnotację @PostConst ru c t, aby sprawdzić, czy ziarno zostało utworzone i czy jego cykl życia się rozpoczął. M etody opatrzone adnotacją @ PostConstruct wywołuje się na nowo utworzonych ziarnach po zakończeniu wstrzykiwania wszystkich zależności, ale przed wywołaniem pierwszej m etody biznesowej. Oczywiście w realnym świecie ziaren singletonowych używa się w innych ziarnach. W dalszych rozdziałach bardziej skupiamy się na integracji i dostępie do ziaren EJB oraz na tym, czy powinny one być singletonami. Przedstawione ziarna zostają uruchom ione wraz z serwerem. Ziarno CacheSingletonBean czeka na swoją kolej, ponieważ zależy od inicjacji ziarna MyLoggingBean. W ynik w rejestratorze powinien być podobny do poniższego: > Jestem pierwszy!!! > Działam!
Ziarno singletonowe może być zależne od inicjacji kilku innych ziaren. W takim przypadku w adnotacji @DependsOn m ożna wymienić kilka ziaren. Poniższe ziarno zależy od ziaren MyLoggingBean i M y In itia liz a tio n B e a n : @Startup @DependsOn({"MyLoggingBean","MyInitializationBean"}) @Singleton public c la ss CacheSingletonBean { / / im plem entacja
} Kolejność inicjacji ziaren MyLoggingBean i M y In itia liz a tio n B e a n determ inują ich własne adnotacje @DependsOn. Jeżeli żadne ziarno nie zależy wprost od innego, kontener inicjuje je w nieokreślonej kolejności.
Implementacja wzorca Singleton w Javie EE
| 67
Współbieżność Największe problem y sprawia współbieżność. W implementacji Javy EE nie trzeba przejmować się tworzeniem ziaren, ale nadal należy uważać na dostęp do m etod, ponieważ singleton może być używany w środowisku współbieżnym. W Javie EE również i ten problem jest rozwiązywany przy użyciu adnotacji. W Javie EE rozróżnia się dwie techniki obsługi współbieżności: współbieżność zarządzaną przez kontener i współbieżność zarządzaną przez ziarno. We współbieżności zarządzanej przez kontener wszystkim, co m a związek z odczytywaniem i zapisywaniem, zajmuje się kontener, natom iast we współbieżności zarządzanej przez ziarno obsługa współbieżności należy do obowiązków programisty, który m usi używać tradycyjnych m etod Javy, takich jak np. synchronizacja. W spółbieżność zarządzaną przez ziarno włącza się przy użyciu adnotacji ConcurrencyManagementType.BEAN. W Javie EE obsługa współbieżności zarządzanej przez kontener jest stosowana domyślnie, ale m ożna ją zdefiniować jawnie za pom ocą adnotacji ConcurrencyManagementType. CONTAINER: @Startup @DependsOn("MyLoggingBean") @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) @Singleton public class CacheSingletonBean { II im plem entacja
} Wracając do przykładu, teraz wykorzystamy adnotacje @Lock do kontrolowania dostępu — listing 4.11. Listing 4.11. Zarządzanie współbieżnością przy użyciu adnotacji @Lock package com.devchronicles.singleton; import import import import import import import import import import import
java.util.HashMap; java.util.Map; javax.annotation.PostConst ruct; javax.ejb.ConcurrencyManagement; javax.ejb.ConcurrencyManagementType; javax.ejb.DependsOn; javax.ejb.EJB; javax.ejb.Lock; javax.ejb.LockType; javax.ejb.Singleton; javax.ejb.Startup;
@Startup @DependsOn("MyLoggingBean") @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) @Singleton public class CacheSingletonBean12 { private Map myCache; @EJB MyLoggingBean loggingBean; @PostConstruct public void start() {
68
I
ROZDZIAŁ 4. Wzorzec Singleton
loggingBean.logInfo("D ziałam !"); myCache = new HashMap (); } @Lock(LockType.WRITE) public void addU ser(Integer id , S tring name) { myCache.put(id, name); } @Lock(LockType.READ) public S tring getName(Integer id) { return myCache.get(id); } } Dostęp do m etod biznesowych ziaren kontrolują dwie blokady — @Lock(LockType .WRITE) (blokuje dostęp do ziarna innym klientom podczas wywoływania metody) i @Lock(LockType. READ) (zezwala na równoczesny dostęp do metody wielu klientów). Metody zmieniające dane są zazwyczaj oznaczane adnotacją typu WRITE, aby zablokować dostęp do tych danych podczas ich zmieniania. W tym przykładzie blokadę typu WRITE m a m etoda addUse r ( ) , więc jeśli któryś klient wywoła metodę getName(), będzie musiał najpierw poczekać na zakończenie działania metody addU ser(). Jeśli m etoda addUser nie zakończy działania w określonym czasie, to kontener może być zmuszony zgłosić wyjątek ConcurrentA ccessTim eoutException. Długość czasu oczekiwania m ożna ustawić za pom ocą adnotacji w sposób pokazany na listingu 4.12. Listing 4.12. Definiowanie limitu czasu dostępu współbieżnego do singletonu package com .devchronicles.singleton; import import import import import import import import import import import import import
javax.annotation.P ostC onst r u c t; jav a x .e jb .S in g le to n ; ja v a x .e jb .S ta rtu p ; javax.ejb.DependsOn; javax.ejb.ConcurrencyManagement; javax.ejb.ConcurrencyManagementType; javax.ejb.AccessTim eout; jav a.u til.M ap ; javax.ejb.EJB ; java.util.H ashM ap; javax.ejb.L ock; javax.ejb.LockType; jav a.u til.co n cu rren t.T im eU n it;
@Startup @DependsOn("MyLoggingBean") @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) @Singleton @AccessTimeout(value = 120000) // domyślna jednostka to milisekunda public c la ss CacheSingletonBean { p riv a te Map myCache; @EJB MyLoggingBean loggingBean; @PostConstruct public void start() {
Gdzie i kiedy używać wzorca Singleton
I 69
loggingBean.logInfo("D ziałam !"); myCache = new HashMap (); } @AccessTimeout(value = 30, u n it = TimeUnit.SECONDS) @Lock(LockType.WRITE) public void addU ser(Integer id , S tring name) { myCache.put(id, name); } @Lock(LockType.READ) public S tring getName(Integer id) { return myCache.get(id); } } Adnotację LockType można ustawiać na poziomie klasy. M a ona wówczas zastosowanie do wszystkich m etod biznesowych, które nie mają własnej adnotacji LockType. Jako że domyślny typ blokady to WRITE, zazwyczaj wystarczy tylko skonfigurować metody wymagające dostępu współbieżnego. W artością TimeUnit adnotacji @AccessTimeout może być jedna z kilku stałych — NANOSECONDS, MICROSECONDS, MILLISECONDS oraz SECONDS. Jeśli nie jest podana żadna jednostka, domyślnie stosowane są milisekundy. Tę adnotację również m ożna stosować na poziomie całej klasy i wówczas dotyczy wszystkich metod, które nie mają jej definicji.
Gdzie i kiedy używać wzorca Singleton Z reguły obecność dużej liczby singletonów może być oznaką tego, że ktoś nie rozumie, do czego one służą. Uzasadnione przypadki użycia tego rodzaju obiektów to np.: buforowanie często używanych, ale trudnych do załadowania zasobów, współużytkowanie danych globalnych oraz używanie jednego punktu kontaktowego (np. rejestratora dziennikowego). Tworzenie i buforowanie niepotrzebnych zasobów odbija się na zużyciu pamięci, zasobów CPU oraz czasu uruchamiania programu. Dlatego singletonów do buforowania należy używać z umiarem. Mimo to obiekty singletonowe bywają bardzo przydatne, a ich konfiguracja w kontenerach Javy EE jest wyjątkowo łatwa. Jeśli potrzebujesz zaawansowanych rozwiązań z dziedziny buforowania, lepszym wyjściem będzie skorzystanie z jakiegoś systemu szkieletowego, np. powszechnie używanego Ehcache (http:IIwww.ehcache.org/) czy rozproszonego systemu buforującego fundacji Apache o nazwie Java Caching System (http/Icommons.apache.orglproperlcommons-jcsI). Za pom ocą singletonu m ożna kontrolować dostęp do systemów zaplecza, które nie są bezpieczne wątkowo albo m ają problem y z licencjonowaniem. Stosowanie adnotacji LockType. WRITE do m etod umożliwia sekwencyjny dostęp do takich systemów, w których wielokrotny dostęp współbieżny powodowałby problemy z wydajnością lub licencjonowaniem.
Podsumowanie Nadmieniliśmy, że wzorzec Singleton popadł w niełaskę do tego stopnia, że wielu programistów i architektów uważa go już za antywzorzec. W śród przyczyn tego można wymienić fakt, że był nadużywany, oraz problemy, jakie sprawia w aplikacjach wielowątkowych.
70
I
ROZDZIAŁ 4. Wzorzec Singleton
Programiści nadużywali tego wzorca, ponieważ łatwo się go implementuje. W efekcie dochodziło do tego, że wszystkie klasy były singletonowe. Spędzało to sen z powiek program istów zajmujących się obsługą serwisową kodu i było jeszcze gorszym cierniem w oku tych, którzy musieli takie twory przerabiać z powrotem na kod obiektowy, gdy okazywało się, że potrzeba więcej niż jednego egzemplarza jakiejś klasy, która została początkowo zaimplementowana jako singleton. Stosowanie klas singletonowych utrudnia też testowanie programów, ponieważ w celu przeprowadzenia prostego testu jednostkowego należy utworzyć egzemplarze globalnych stanów. Ponadto singletony sprawiają, że testy są mniej deterministyczne, ponieważ stany mogą się zmieniać i wpływać na wyniki testów. W przykładach przedstawiliśmy kilka problemów, jakie sprawia posługiwanie się singletonami w środowiskach wielowątkowych. Przed Javą SE 5 i wprowadzeniem do niej typów wyliczeniowych bardzo trudno było utworzyć bezpieczny wątkowo singleton. Ale postęp, jaki dokonał się w Javie EE, sprawił, że problem bezpieczeństwa wątkowego singletonów został w dużym stopniu rozwiązany przy użyciu adnotacji @ Singleton i współbieżności zarządzanej przez kontener. Kontener kontroluje tworzenie singletonu i uniemożliwia wywoływanie m etod biznesowych przed zakończeniem działania m etody oznaczonej adnotacją @PostConst ru c t. Ponadto kontroluje on współbieżny dostęp do ziarna przez adnotację @ConcurrencyManagement, a związana z nią adnotacja @LockType umożliwia precyzyjną kontrolę pojedynczych metod. Oczywiście nie wszystkie problem y związane z używaniem singletonów zostały rozwiązane. Nadal m ożna mieć z nim i kłopoty w środowiskach wielowęzłowych, jeśli ziarno będzie używało niebezpiecznych wątkowo zasobów zaplecza. Ponadto mogą się pojawić problemy występowania wąskich gardeł i zbyt ścisłych powiązań międzyklasowych. Mimo że wzorzec projektowy Singleton z powodu nadużywania przez programistów został skazany na banicję i strącony do otchłani antywzorców, należy przyznać, że znacznie dojrzał od czasu pojawienia się jego pierwszego opisu w książce Bandy Czworga i zasługuje na rehabilitację jako cenny i przydatny wzorzec projektowy.
ĆWICZENIA 1.
Zaprojektuj licznik odwiedzin strony internetowej przy użyciu dwóch metod — jedna niech zwiększa wartość licznika, a druga niech pobiera jego ostatnią wartość. Zapewnij bezpieczeństwo wątkowe swojego rozwiązania, stosując odpowiednie typy blokad.
2.
Zaprojektuj prosty bufor do przechowywania listy książek dla aplikacji do zarządzania biblioteką. Dane powinny być ładowane do bufora w czasie uruchamiania programu. Zdefiniuj metody wyszukujące książki według różnych kryteriów, np.: po numerze ISBN, autorze i gatunku.
3.
Zaprojektuj złożony bufor odczytujący dane z bazy danych podczas uruchamiania programu. Metody pobierające dane powinny najpierw szukać tych danych w buforze i dopiero gdy ich tam nie znajdą, ziarno powinno sięgać do bazy danych. Jeżeli potrzebne dane zostaną znalezione w bazie danych, należy je zapisać w buforze.
4.
Dodaj do rozwiązania ćwiczenia 3. mechanizm usuwający rzadko używane dane z bufora i aktualizujący przestarzałe informacje. Zadbaj o prawidłowe zarządzanie całym cyklem życia bufora.
5 Wstrzykiwanie zależności i CDI
ZAWARTOŚĆ ROZDZIAŁU:_______ > wprowadzenie do technik wstrzykiwania zależności; > znaczenie wstrzykiwania zależności w Javie EE; > implementacja wstrzykiwania zależności w zwykłym kodzie; > implementacja wstrzykiwania zależności w Javie EE; > wprowadzenie do kontekstowego wstrzykiwania zależności; > najważniejsze różnice dzielące kontenery CDI i EJB.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r05, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. Wstrzykiwanie zależności (ang. Dependency Injection — DI) to jeden z nielicznych powszechnie znanych i stosowanych wzorców projektowych, które nie zostały opisane w książce Bandy Czworga1. Ale obecnie wzorzec ten jest wykorzystywany w nowoczesnych językach programowania zarówno do implementacji mechanizmów wewnętrznych, jak i jako środek do rozluźniania powiązań między klasami. Technologia J2EE miała służyć do budowania najbardziej złożonych systemów, ale spisała się marnie, ponieważ tylko nadmiernie komplikowała proces tworzenia nawet prostszych systemów. Pierwotny projekt J2EE był oparty na wysokim poziomie złożoności i ścisłych powiązaniach między klasami, 1 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogram owania obiektowego wielokrotnego użytku, H elion, 2010.
72
I
ROZDZIAŁ 5. Wstrzykiwanie zależności i CDI
co stało się bodźcem do powstania i spopularyzowania różnych systemów szkieletowych, takich jak Spring czy PicoContainer. W 2004 r. Martin Fowler opublikował artykuł na temat kontenerów odwróconego sterowania (ang. Inversion o f Control — IoC) i wzorca wstrzykiwania zależności2. Większość producentów oprogramowania nie zachęcała programistów do używania kontenera J2EE. Wkrótce kontrolę przejęły lekkie kontenery, które zaczęto oficjalnie obsługiwać, i na dodatek Spring stał się w zasadzie nieoficjalnym standardem, doprowadzając do tego, że Javę biznesową postanowiono zaprojektować od nowa.
Na czym polega wstrzykiwanie zależności Wzorzec Wstrzykiwanie Zależności opiera się na pomyśle odwrócenia tego, do kogo należy kontrola. Zamiast tworzyć zależności i nowe obiekty za pomocą słowa kluczowego new lub przy użyciu operacji wyszukiwania, potrzebne zasoby wstrzykuje się do obiektu docelowego. Podejście to m a wiele zalet: ^
Klient nie m usi wiedzieć o różnych implementacjach wstrzykiwanych zasobów, co ułatwia wprowadzanie zm ian w projekcie.
^
Znacznie łatwiej implementuje się testy jednostkowe z wykorzystaniem atrap obiektów.
^
Konfigurację m ożna przenieść na zewnątrz, redukując w ten sposób skutki zmian.
^
Architektura oparta na luźnych powiązaniach ułatwia tworzenie systemów wtyczkowych.
Podstawową ideą techniki wstrzykiwania zależności jest zmiana miejsca tworzenia obiektów oraz wykorzystanie wtryskiwacza (ang. injector) do wstrzykiwania w odpowiednim momencie specyficznych implementacji do obiektów docelowych. Może się to wydawać podobne do implementacji wzorca Fabryka (opisanego w rozdziale 6., „Wzorzec Fabryka”), ale koncepcja ta jest znacznie bardziej zaawansowana niż proste tworzenie obiektu. Odwrócenie sterowania całkowicie wywraca do góry nogami relacje między obiektami i przekazuje całą pracę do wtryskiwacza (który w większości przypadków działa magicznie). Zamiast wywoływać fabrykę, aby dostarczyć implementację wywołującemu, wtryskiwacz aktywnie sprawdza, kiedy obiekt docelowy potrzebuje obiektu źródłowego, i dokonuje wstrzyknięcia w odpowiedni sposób.
Implementacja wstrzykiwania zależności w zwykłym kodzie Standardowa implementacja wstrzykiwania zależności w Javie poza kontenerem EJB jest dostępna dopiero od czasu wprowadzenia CDI (ang. Context and Dependency Injection). Choć istnieją różne systemy szkieletowe, jak choćby Spring i Guice, nietrudno jest samodzielnie zaimplementować podstawowe rozwiązanie. Najprostsza implementacja wzorca Wstrzykiwanie Zależności to fabryka tworząca zależność na żądanie przy użyciu m etody g e tI n s ta n c e ( ). Poniżej przedstawiamy taką implementację, aby pokazać, jak to się robi w zwykłym kodzie. W implementacji tej powinno się oddzielić rozwiązywanie zależności od zachowania klasy. Oznacza to, że klasa pow inna mieć określoną funkcjonalność bez definiowania tego, jak pozyskuje referencje do klas, od których zależy. W ten sposób rozłącza się operację tworzenia obiektu i miejsce jego użycia — a to jest esencją wstrzykiwania zależności. 2 M a rtin Fow ler, Inversion o f C ontrol C ontainers a n d the D ependency Injection P attern, 2004, http://m artinfow ler.com /articles/injection.htm l.
Implementacja wstrzykiwania zależności w zwykłym kodzie
| 73
Najpierw na listingach: 5.1, 5.2, 5.3 i 5.4 przedstawimy przykłady silnie powiązanych klas, a następnie zmienimy je zgodnie z zasadami wzorca Wstrzykiwanie Zależności. Listing 5.1. Klasa UserService tworząca nową zależność w konstruktorze package com .devchronicale.di; c la ss UserService { p riv a te UserDataRepository udr; UserService() { th is .u d r = new UserDataRepositoryImpl(); } public void persistU ser(U ser user) { udr.save(user) ; } } Listing 5.2. Interfejs UserDataRepository package com .devchronicale.di; public in te rfa c e UserDataRepository { public void save(User u s e r ) ; } Listing 5.3. Konkretna implementacja interfejsu UserDataRepository package com .devchronicale.di; public c la ss UserDataRepositoryImpl implements UserDataRepository { @Override public void save(User user) { II zapisyw anie danych
} } Listing 5.4. Klasa User package com .devchronicale.di; public c la ss User { I I kod dotyczący użytko w n ika
} Przedstaw iona na listingu 5.1 klasa U se rS e rv ic e dostarcza usługi logiki biznesowej do zarządzania użytkownikam i, np. do zapisywania inform acji o użytkownikach w bazie danych. W tym przykładzie obiekt jest tw orzony przez konstruktor, co wiąże logikę biznesową (zachowanie klasy) z tw orzeniem obiektu. Teraz zdejmiemy obowiązek tworzenia obiektu z naszej klasy i przeniesiemy go do fabryki. Na listingu 5.5 tworzona jest implementacja klasy U serD ataR epository, którą przekazujemy do konstruktora klasy U serService. Trzeba było zmienić konstruktor klasy U serService, aby przyjmował nowy param etr.
74
| ROZDZIAŁ 5. Wstrzykiwanie zależności i CDI
Listing 5.5. Klasa UserServiceFactory tworząca obiekty klasy UserService package com .devchronicale.di; public c la ss UserServiceFactory { public UserService g e tIn sta n c e () { return new UserService(new U serDataRepositoryImpl()); } } Na listingu 5.6 konstruktor U serService żąda „wstrzyknięcia” egzemplarza klasy UserDataRepository. Klasa U serS ervice nie jest sprzężona z klasą U serD ataReposityIm pl. Teraz to zadaniem fabryki jest tworzenie obiektu i „wstrzykiwanie” im plem entacji do konstruktora klasy U serService. W ten sposób oddzieliliśmy logikę biznesową od operacji tworzenia obiektów. Listing 5.6. Zmieniona klasa UserService package com .devchronicale.di; c la ss UserService { p riv a te UserDataRepository udr; UserService(UserDataRepository u d r) { th is .u d r = udr; } public void p ersistU ser(U ser u se r) { u d r.sa v e (u se r) ; } } OPOWIADANIE WOJENNE Gdy powierzono mi zadanie napisania aplikacji na Androida, postanowiłem poszukać systemów szkieletowych ze wstrzykiwaniem zależności dla platform mobilnych. Jako programista z doświadczeniem w sektorze biznesowym myślałem, że to najlepsze rozwiązanie. Interfejs użytkownika Androida wykorzystuje przecież strukturę przypominającą wstrzykiwanie zależności, wiążącą składniki interfejsu zdefiniowane w XML-u z kodem Javy, więc wydawało mi się, że implementacja kompletnego systemu wstrzykiwania zależności jest dobrym pomysłem, który pozwoli osiągnąć oszałamiające rezultaty. Opracowałem piękną architekturę, w której wszystkie obiekty i zasoby były ze sobą powiązane. Wstrzykiwanie działało pięknie, ale aplikacja... nie. Uruchamiała się 0 wiele dłużej niż inne podobne aplikacje i szwankowała też w niej nawigacja. Wszyscy zakładaliśmy, że elegancki system złożony z luźno powiązanych składników da się utworzyć tylko przy użyciu wstrzykiwania zależności, więc nawet nie przyszło nam do głowy szukać źródła problemów właśnie w tej technice. Stworzyliśmy piękny 1lekki interfejs użytkownika oraz wykorzystaliśmy asynchroniczne zadania działające w tle, aby nie blokować aplikacji niektórymi operacjami oraz zmniejszyć ilość pracy podczas uruchamiania programu. Jednak wszystko na próżno.
Implementacja wstrzykiwania zależności w Javie EE
| 75
W końcu dotarło do nas, że problemem jest wstrzykiwanie zależności. Aplikacja podczas uruchamiania i wykonywania niezbędnych czynności początkowych wyszukiwała wszystkie zasoby do wstrzykiwania i referencje. W serwerze, który uruchamia się nieczęsto, ma wielu użytkowników, jest rzadko restartowany i dysponuje gigantyczną ilością pamięci, może i byłoby to dobre. Ale w przypadku urządzenia przenośnego, które ma jednego użytkownika, jest często restartowane i dysponuje niewielką ilością pamięci, ponieśliśmy sromotną klęskę. Rozwiązanie polegało na powiązaniu ze sobą zasobów. Choć kod zrobił się „brzydszy", to aplikacja stała się szybka jak błyskawica, co zakończyło nasze problemy z wydajnością. Morał z tej historii nie jest taki, że wstrzykiwanie zależności nie jest odpowiednią techniką do stosowania w urządzeniach przenośnych, tylko taki, że jeśli się ją nieprawidłowo zaimplementuje (nieważne, w jakim urządzeniu) w nieodpowiednim kontekście, to można mieć poważne kłopoty.
Implementacja wstrzykiwania zależności w Javie EE Standardowo w J2EE nie było wstrzykiwania zależności aż do Javy EE 5. Zamiast tego w tamtych czasach dostęp do ziaren i zasobów był realizowany przy użyciu interfejsu wyszukiwania kontekstowego (ang. Java N am ing and Directory Interface — JNDI). W adą tej m etody było zacieśnianie powiązań między składnikami i wykorzystywanie ciężkiego serwerowego kontenera, przez co testowanie wcale nie było łatwiejsze od pisania właściwego kodu. Od Javy EE 5 i EJB 3 wstrzykiwanie zależności jest już integralną częścią platformy Enterprise Java. W celu pozbycia się konfiguracji XML wprowadzono kilka adnotacji do wykonywania wstrzyknięć: ^
@Resource (JSR 250) — służy do wstrzykiwania takich zasobów, jak: dane, JMS (ang. Java Message Service), URL, poczta oraz zmienne środowiskowe.
^
@EJB (JSR 220) — służy do wstrzykiwania ziaren EJB.
^
@WebServiceRef — służy do wstrzykiwania usług sieciowych.
Od pojawienia się Javy EE 6, CDI oraz EJB 3.1 technika wstrzykiwania zależności stała się znacznie bardziej przydatna, a więc też i bardziej interesująca dla program istów Javy EE. W EJB 3.1 ziarna nie muszą już mieć interfejsów. Ponadto wprowadzono nowy interfejs sieciowy EJB zapewniający uproszczony i lżejszy kontener EJB. Dodano też nową i ulepszoną adnotację wstrzykiwania @ Inject (JSR 229 i JSR 330), która stanowiła wspólny interfejs do wstrzykiwania dla różnych systemów z królestwa Javy. Wstrzykiwanie przy użyciu adnotacji @ Inject jest bezpieczne pod względem typów, ponieważ odbywa się na podstawie typu referencji do obiektu. Gdybyśmy chcieli dostosować do nowych zasad kod z listingu 5.1, usunęlibyśmy z niego konstruktor i dodalibyśmy adnotację @ Inject do pola U serD ataR epository. Wyglądałoby to tak jak na listingu 5.7.
76
I
ROZDZIAŁ 5. Wstrzykiwanie zależności i CDI
Listing 5.7. Klasa UserService z użyciem adnotacji @Inject package com .devchronicale.di; import ja v a x .in je c t.I n je c t; class UserService { @Inject p riv a te UserDataRepository udr; public void p ersistU ser(U ser user) { ud r.sav e(u ser); } } Kontener CDI tworzy jeden egzemplarz klasy U serR epositoryIm pl jako ziarno zarządzane przez kontener i wstrzykuje go wszędzie tam, gdzie znajdzie adnotację @ Inject przy polu typu U serD ataR epository. Ziarna zarządzane przez kontener można wstrzykiwać do konstruktorów, m etod i pól bez względu na modyfikator dostępu, ale pole nie może być finalne, a metoda nie może być abstrakcyjna. Powstają pewne ważne pytania. Co się stanie, jeśli będzie więcej niż jedna implementacja interfejsu UserDataRepository? Jak kontener CDI zidentyfikuje implementację do wstrzyknięcia? Aby rozróżnić konkretne implementacje interfejsu U serD ataR epository, dla konkretnych klas m ożna oznaczyć klasę samodzielnie zdefiniowanym kwalifikatorem. W yobraź sobie, że są dwie implementacje interfejsu U serD ataR epository — jedna dla kolekcji M ongo DB (dokum entow a baza danych), a druga dla bazy danych MySQL (relacyjna baza danych). Należałoby utworzyć dwa kwalifikatory (jeden dla im plem entacji Mongo i drugi dla implementacji MySQL) i odpowiednio oznaczać nim i konkretne klasy oraz znajdujące się w nich pola. W eźmy np. klasę U serS ervice z listingu 5.7. Gdybyśmy chcieli użyć implementacji interfejsu U serD ataR epository dla Mongo, dodalibyśmy adnotację @Mongo do pola udr: @Inject @Mongo p riv a te UserDataRepository udr; Bardziej szczegółowy opis kwalifikatorów znajduje się poniżej i w rozdziale 6.
Adnotacja @Named Kolejnym w ielkim w ydarzeniem było w prow adzenie adnotacji @Named w miejsce kw alifikatorów łańcuchowych. W ieloznaczności w zależnościach EJB rozstrzygano przy użyciu łańcucha w atrybucie beanName adnotacji @EJB określającej im plementację do wstrzyknięcia — @EJB(beanName="UserDataRepository" ). Adnotacja @Named umożliwia również rozstrzyganie niejednoznaczności przy użyciu atrybutu łańcuchowego. N a listingu 5.8 im plem entacja Mongo interfejsu U serD ataR ep o sito ry jest wstrzykiwana do pola udr.
Implementacja wstrzykiwania zależności w Javie EE
I 77
Listing 5.8. Wykorzystanie adnotacji @Named do rozstrzygania wieloznaczności package com .devchronicale.di; import ja v a x .in je c t.I n je c t; import javax.inject.N am ed; c la ss UserService { @Inject @Named("UserDataRepositoryMongo") p riv a te UserDataRepository udr; public void p ersistU ser(U ser u s e r) { u d r.sa v e (u se r) ; } } Jawna adnotacja implementacji Mongo jest wymagana przez odpowiadającą jej adnotację @Named. Na listingu 5.9 implementacja Mongo interfejsu U serD ataR epository jest oznaczona adnotacją z taką samą nazwą, jaka została użyta do rozstrzygnięcia wieloznaczności na listingu 5.8. Listing 5.9. Konkretna implementacja wymaga adnotacji @Named package com .devchronicale.di; import javax.inject.N am ed; @Named("UserDataRepositoryMongo") public c la ss UserDataRepositoryMongo implements UserDataRepository { @Override public void save(User user) { / / zapisyw anie danych
} } Wykorzystywanie łańcuchów do identyfikowania zależności to technika przestarzała. Jest ona niebezpieczna dla typów i w specyfikacji CDI JSR 299 odradza się jej stosowanie. Ale da się też użyć adnotacji @Named w taki sposób, aby nie wykorzystywać identyfikatorów łańcuchowych w miejscu wstrzykiwania. @Inject @Named p riv a te UserDataRepository UserDataRepositoryMongo; Na listingu 5.9 nazwa implementacji do wstrzyknięcia jest określana na podstawie nazwy pola UserDataRepositoryMongo. W rzeczywistości adnotacja @Named zostaje zam ieniona na @Named("UserDataRepositoryMongo").
Wstrzykiwanie zależności i kontekst (CDI) Technika CDI (ang. Context and Dependency Injection — kontekst i wstrzykiwanie zależności) wniosła do platform y Java EE kom pletny m echanizm wstrzykiwania zależności, który wcześniej był ściśle związany z EJB i o wiele bardziej ograniczony. Po pojawieniu się EJB 3 w JBoss wprowadzono Seam
78
I
ROZDZIAŁ 5. Wstrzykiwanie zależności i CDI
(system szkieletowy do budowy aplikacji sieciowych), który zdobył całkiem sporą popularność dzięki obsłudze bezpośrednich interakcji między JSF (ang. JavaServer Faces) i JavaBeans oraz EJB. Sukces systemu Seam doprowadził do powstania specyfikacji JSR 299 — WebBeans. Podobnie jak Hibernate, znany system szkieletowy do zapisywania danych dla Javy, był bodźcem do standaryzacji interfejsu API Java Persistence (JPA), Seam stał się inspiracją rdzenia implementacji CDI. CDI współpracuje z każdym zwykłym obiektem Javy (POJO) przez tworzenie i wstrzykiwanie obiektów do innych obiektów. Wstrzykiwać można następujące rodzaje obiektów: >
POJO;
>
zasoby biznesowe, np. dane i kolejki;
>
zdalne referencje EJB;
>
ziarna sesyjne;
>
obiekty typu EntityM anager;
>
referencje do usług sieciowych;
>
pola producenckie i obiekty zwracane przez metody producenckie.
CDI a EJB Choć może się wydawać, że CDI i EJB to technologie konkurencyjne, w rzeczywistości egzystują one w harm onii. CDI może działać bez kontenera EJB. W istocie CDI może być podstawą aplikacji desktopowej lub dowolnej aplikacji sieciowej, która nie korzysta z kontenera EJB. CDI dostarcza fabrykę i wstrzykiwanie do dowolnego ziarna. Natom iast ziarna EJB wymagają kontenera EJB. Nawet uproszczona architektura EJB jest bardziej złożona niż obiekty POJO i dlatego ziarna EJB potrzebują kontenera EJB. Kontener ten zapewnia dodatkowe przydatne usługi, takie jak: zabezpieczenia, transakcje i współbieżność. Mówiąc krótko: kontener CDI jest lżejszym i potężniejszym, ale też mniej funkcjonalnym kontenerem dla obiektów POJO. Jednak oba kontenery są na tyle dobrze ze sobą zintegrowane, że adnotacje CDI mogą służyć jako bram a i standardowy interfejs do interakcji z kontenerem EJB. Na przykład adnotacja @ Inject może być używana zarówno z POJO, jak i EJB oraz może wstrzykiwać dowolną kombinację tych obiektów, wywołując odpowiedni kontener.
Ziarna CDI Ziarno zarządzane przez kontener to trochę więcej niż tylko obiekt POJO spełniający pewne proste wymagania: ^
Musi mieć bezargumentowy konstruktor lub konstruktor deklarujący adnotację @ Inject.
^
Klasa musi być konkretna i znajdować się na najwyższym poziomie hierarchii albo być opatrzona adnotacją @Decorate. Nie może być to niestatyczna klasa wewnętrzna.
^
Ziarno nie może być zdefiniowane jako EJB.
^
Jeśli ziarno jest zdefiniowane jako zarządzane przez inną technologię Javy EE, np. JSF, to również będzie zarządzane przez ten kontener.
Obiekty każdej klasy spełniającej te wymagania są tworzone i zarządzane przez kontener i mogą być wstrzykiwane. Nie trzeba żadnej specjalnej adnotacji, aby oznaczyć klasę jako ziarno zarządzane.
Implementacja wstrzykiwania zależności w Javie EE
| 79
Kontener szuka ziaren w archiwach ziaren. W yróżnia się dwa typy takich archiwów — jawne i niejawne. Archiwum jawne zawiera deskryptor wdrożenia bean.xml, który z reguły pozostaje pusty. CDI skanuje klasy w archiwum w poszukiwaniu klas spełniających opisane powyżej wymagania stawiane ziarnom oraz przejmuje do zarządzania i wstrzykiwania wszystkie te z nich, które nie mają adnotacji @Vetoed. Adnotacja ta wyklucza klasę z grupy klas zarządzanych przez kontener. W niektórych przypadkach nie jest pożądane zezwolenie kontenerowi na zarządzanie wszystkimi znalezionymi ziarnami, które spełniają warunki. Jeśli trzeba ograniczyć grupę klas, które zostaną przyjęte przez kontener CDI do zarządzania, m ożna zdefiniować własność bean-discovery-m ode w deskryptorze wdrożenia bean.xml. Na listingu 5.10 pokazano fragment tego pliku zawierający własność bean-discovery-m ode z wartością a l l . Listing 5.10. Tryb wykrywania ziaren ustawia się w pliku bean.xml Własności bean-discovery-m ode można przypisać jedną z trzech wartości: a l l , none lub annotated. Ustawienie a l l oznacza dla kontenera CDI, że m a zarządzać wszystkimi znalezionymi w archiwum ziarnami. Jest to wartość domyślna. Ustawienie none oznacza, że kontener CDI m a w ogóle nie zarządzać ziarnami, a a n n o tated sprawia, że archiwum zachowuje się jak archiwum niejawne. W takim przypadku kontener szuka ziaren z adnotacjami oznaczającymi ich zakres. Niejawne archiwum ziaren nie zawiera deskryptora wdrożenia bean.xml. Stanowi to dla kontenera CDI sygnał, że powinien zarządzać tylko ziarnami z określonym zakresem. Więcej informacji na tem at zakresów ziaren znajduje się w punkcie „Konteksty i zakres”.
Adnotacja @Inject Właściwości adnotacji @Inj e c t zostały już opisane. Zanim wprowadzono technologię CDI do Javy EE, każdy system szkieletowy wstrzykiwania zależności działał na swój sposób. Kiedy w Javie EE zastosowano kontener CDI, który miał pracować obok kontenera EJB, adnotacja @ Inject stała się jedynym i abstrakcyjnym interfejsem dla prawie wszystkich operacji wstrzykiwania. Dzięki niej m ożna używać każdego kontenera lub systemu szkieletowego wstrzykiwania zależności odpowiedniego w danym przypadku.
Konteksty i zakres Kontekst jest tym, co odróżnia kontenery EJB od CDI. Cykl życia ziarna CDI jest powiązany z zakresem kontekstowym. Istnieją cztery zakresy CDI: ^
@RequestScoped — zakres obejmuje żądanie HTTP użytkownika.
^
@SessionScoped — zakres obejmuje sesję HTTP użytkownika.
^
@ApplicationScoped — stan jest współdzielony przez wszystkich użytkowników w aplikacji.
^
@ConversationScoped — zakres jest kontrolowany przez programistę.
80
I
ROZDZIAŁ 5. Wstrzykiwanie zależności i CDI
Ziarno opatrzone adnotacją określającą zakres przechowuje stan przez cały ten zakres i współdzieli ten stan z każdym klientem działającym w tym samym zakresie. Na przykład ziarno o zakresie żądania przechowuje stan przez cały czas istnienia żądania HTTP, a ziarno o zakresie sesji przechowuje stan przez cały czas istnienia sesji HTTP. Ziarno z zakresem jest automatycznie tworzone w razie potrzeby i niszczone na końcu kontekstu, w którym bierze udział. Adnotacje zakresowe są często używane do określania zakresu ziaren wykorzystywanych przez język EL (ang. Expression Language) w faceletach.
Nazewnictwo i EL Ziarno z adnotacją @Named jest dostępne poprzez język EL. Domyślnie w wyrażeniu należy użyć nazwy klasy, tylko zm ienić pierwszą literę na małą. W odniesieniach do m etod dostępowych zaczynających się od przedrostka g e t lub i s należy opuścić tę cząstkę. Na listingu 5.11 pokazano stosowny przykład. Listing 5.11. Adnotacja @Named sprawia, że ziarno staje się widoczne dla EL package com .devchronicale.di; import j avax.enterprise.context.R equestScoped; import j avax. in j ect.Named; @Named / / Defining th a t th is i s a managed bean @RequestScoped / / Defines the scope public c la ss User { p riv a te S tring fullName; public S tring getFullName() { return th is .fullName; } / / dalsze m etody usunięte dla uproszczenia
} Jest to prosta implementacja nazwanego ziarna zwracającego łańcuch, gdy zostanie wywołana m etoda getFullName (). W facelecie do m etody tej należałoby odnieść się za pomocą nazwy u se r. fullnam e.
Ziarna CDI jako wsparcie dla JSF Jak w poprzednim przykładzie, ziarna CDI mogą służyć jako ziarna wspierające dla stron JSF. Dostęp do nazwanych ziaren m ożna uzyskać poprzez ich nazwę z pierwszą literą zm ienioną na małą. Dostęp do pól i m etod dostępowych na stronach JSF m ożna uzyskać zgodnie z konwencjami Javy. Technologia JSF nie jest tem atem tej książki, ale na listingu 5.11 pokazano przykład wykorzystania ziaren CDI z JSF.
Implementacja wstrzykiwania zależności w Javie EE
| 81
Kwalifikatory W tym podrozdziale opisujemy sposoby tworzenia własnych klas kwalifikatorów. Na listingu 5.12 tworzymy kwalifikator o nazwie Mongo, przy użyciu którego m ożna dodawać adnotacje do pól. Jeśli chcesz zastosować tę adnotację do metody, parametru lub klasy albo interfejsu (typu), to możesz ją dodać do adnotacji @Target. Listing 5.12. Tworzenie kwalifikatora o nazwie @Mongo package com .devchronicale.di; import s t a t i c java.lang.annotation.Elem entT ype. FIELD ; import s t a t i c ja v a.lan g .an n o tatio n .R eten tio n P o licy . RUNTIME ; import j a v a .la n g .a n n o tatio n .R ete n tio n ; import j av a.lan g .an n o tatio n .T arg et; import j avax. in j e c t.Q u a lifie r; @Qualifier @Retention(RUNTIME) @Target({ FIELD} ) public @ interface Mongo {} Szerzej na tem at różnych zastosowań adnotacji piszemy w rozdziale 6.
Alternatywy W przedstawionych przykładach pokazaliśmy, jak za pomocą kwalifikatorów odróżnić od siebie dwie różne implementacje interfejsu U serD ataR epository. Takich wyborów implementacji dokonuje się z reguły w czasie pisania program u, wprowadzając odpowiednie zmiany w kodzie. Ale w razie potrzeby można też zrobić to podczas wdrażania program u za pomocą adnotacji @Alte rn a tiv e i kilku linijek konfiguracji w deskryptorze wdrożenia bean.xml. Korzystając z dotychczasowych przykładów, oznaczymy nasze dwie implementacje interfejsu U serD ataR epository adnotacją @ A lternative oraz zdefiniujemy odpowiednią konfigurację w pliku bean.xml. W niej zdecydujemy, którą implementację należy wstrzyknąć. @ Alternative public c la ss UserDataRepositoryMongo implements UserDataRepository { . . . } @ Alternative public c la ss UserDataRepositoryMySQL implements UserDataRepository { . . . } Implementację wykorzystywaną w aplikacji deklarujemy w pliku bean.xml: < altern ativ es> com.devchronicale.di.UserDataRepositoryM ongo < /a lte rn a tiv e s> Alternatywy często są wykorzystywane w fazie testowania program u do tworzenia atrap obiektów.
82
| ROZDZIAŁ 5. Wstrzykiwanie zależności i CDI
Stereotypy Stereotypy m ożna sobie wyobrażać jako szablony definiujące cechy typu ziarna. N a przykład ziarno wykorzystywane na poziom ie m odelu w aplikacji zbudowanej według wzorca Model - W idok - Kontroler (MVC) do działania wymaga pewnych adnotacji. Mogą to być np. te: @Named @RequestScoped @Stereotype @Target({TYPE, METHOD, FIELD}) @Retention(RUNTIME) Do zdefiniowania ziarna modelowego niezbędne są tylko adnotacje @Named i @RequestScoped. Pozostałe są potrzebne do utworzenia adnotacji o nazwie @Model. W razie potrzeby do każdego ziarna m ożna przypisać wszystkie te adnotacje albo można zdefiniować stereotyp o nazwie @Model i tylko jego używać w przypadku ziaren. To drugie rozwiązanie znacznie upraszcza kod i ułatwia jego obsługę serwisową. Aby utworzyć stereotyp, definiuje się nową adnotację i stosuje się wymagane adnotacje, jak pokazano na listingu 5.13. Listing 5.13. Adnotacja stereotypowa @Named @RequestScoped @Stereotype @Target({TYPE, METHOD, FIELD}) @Retention(RUNTIME) public @ interface Model {} Każde ziarno z adnotacją @Model m a zakres żądania (@RequestScoped) i jest widoczne dla EL (@Named). Na szczęście kontener CDI z tym stereotypem został już zdefiniowany. Adnotacji stereotypowych najczęściej używa się w kombinacji z adnotacją alternatywną do oznaczania obiektów atrapowych.
Inne wzorce związane z CDI Technologia CDI dała program istom Javy EE wiele nowych możliwości. Nie jest ona tylko prostym systemem szkieletowym wstrzykiwania zależności, lecz znacznie ułatwia im plem entow anie różnych wzorców. W kolejnych rozdziałach znajduje się szczegółowy opis tych wzorców projektowych. Poniżej zamieściliśmy krótkie wprowadzenie na zaostrzenie apetytu. W rozdziale 7., „Wzorzec D ekorator”, znajduje się opis wzorca Dekorator. Dekoratory opakowują obiekty docelowe, aby dynamicznie dodać nowe obowiązki. Każdy dekorator m ożna opakować w inny dekorator, co teoretycznie umożliwia utworzenie nieskończonej liczby dekorowanych obiektów docelowych w czasie działania program u. W zorzec Dekorator wykorzystuje adnotacje @Decorator i @Delegate. Kolejność dekorowania określa się w pliku bean.xml. W rozdziale 6. opisany jest wzorzec Fabryka. Fabryki ograniczają do m inim um wykorzystanie słowa kluczowego new i m ogą zawierać proces inicjacji oraz różne konkretne implementacje. W zorzec Fabryka wykorzystuje adnotację @Produces do oznaczania m etod producenckich. Obiekt docelowy może wstrzyknąć lub obserwować wyprodukowane obiekty.
Podsumowanie
| 83
W rozdziale 11. znajduje się opis wzorca Obserwator i zdarzeń. W zorzec ten zmienia kierunek przepływu wiadomości, czyli kolejność wywołującego i wywoływanego. Przy użyciu tego wzorca nie trzeba agresywnie sprawdzać zasobu, tylko m ożna subskrybować zmiany zachodzące w zasobie. W zorzec Obserwator w Javie EE wykorzystuje adnotację @Observes i zdarzenia. Obserwatory docelowe mogą obserwować wszystkie zdarzenia. Tematem rozdziału 8. są aspekty i interceptory. Przy ich użyciu m ożna zmienić sposób wykonywania kodu w czasie działania program u. Każdy aspekt lub interceptor może zatrzymać wykonywanie i włączyć się w wybranym miejscu. Umożliwia to dynamiczne wprowadzanie zmian nawet w dużych programach.
Podsumowanie W tym rozdziale przedstawiliśmy techniki wstrzykiwania zależności w Javie EE. Koncepcja ta umożliwia rozluźnienie więzi między składnikami systemu łatwiej, niż można by się było spodziewać. Pokazaliśmy, jak wstrzykiwanie zależności umożliwia pozbycie się słowa kluczowego new, a więc uniknięcie ręcznego tworzenia obiektów. Sporo miejsca poświęciliśmy też technologii CDI, która dzięki wykorzystaniu nowego kontenera stwarza całkiem nowe możliwości. Przy jej użyciu wstrzykiwanie zależności m ożna stosować do wszystkich obiektów, a implementacja innych wzorców opisanych w tej książce jest znacznie łatwiejsza.
ĆWICZENIA 1.
Zaprojektuj klasę usługową zwracającą do klienta dowolny łańcuch.
2.
Zaimplementuj czytnik plików i wstrzyknij go do wcześniej utworzonej usługi.
3.
Zaimplementuj obiekt odczytujący jako łańcuch treść HTML z określonego na stałe adresu URL.
4.
Zastanów się, co musisz zmienić w klasie usługowej, aby móc wstrzykiwać obu dostawców danych przy użyciu tej samej referencji.
5.
Czy da się dynamicznie wstrzyknąć wybraną implementację w zależności od pewnych warunków? Na przykład czy można sprawić, aby czytnik plików był wstrzykiwany podczas pracy nad programem, a czytnik HTTP w produkcji?
84 | ROZDZIAŁ 5. Wstrzykiwanie zależności i CDI
6 Wzorzec Fabryka
ZAWARTOŚĆ ROZDZIAŁU:_______ > cechy wzorca projektowego Fabryka i jego zastosowanie; > sposoby implementacji różnych rodzajów wzorca Fabryka — Metoda Fabryczna i Fabryka Abstrakcyjna; > sposób implementacji wzorca Fabryka w Javie EE przy użyciu adnotacji @Producers i @Inject; > tworzenie własnych adnotacji i sposób użycia adnotacji @ Qualifier do rozróżniania konkretnych implementacji.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r06, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. Fabryka to jeden z najczęściej wykorzystywanych podstawowych wzorców projektowych w nowoczesnych językach programowania. Używają go nie tylko programiści zwykłych programów i aplikacji sieciowych, ale również programiści systemów wykonawczych i szkieletowych, jak Java i Spring. W zorzec Fabryka występuje w dwóch wersjach: M etoda Fabryczna i Fabryka Abstrakcyjna. W obu przypadkach cel jest taki sam — zapewnienie interfejsu do tworzenia rodzin powiązanych lub wzajemnie zależnych obiektów bez określania ich konkretnych klas. W tym rozdziale opisano obie wersje wzorca oraz pokazano przykłady ich implementacji. Pokazujemy sposób implementacji Fabryki w Javie SE, a także opisujemy, czym on się różni od implementacji w Javie EE oraz jak jest wykorzystywane kontekstowe wstrzykiwanie zależności.
86
| ROZDZIAŁ 6. Wzorzec Fabryka
Czym jest Fabryka Fabryka należy do konstrukcyjnych wzorców projektowych, więc opisuje sposób tworzenia obiektów. Logika konstruowania obiektów znajduje się w fabryce, która udostępnia metody zwracające nowo utworzone obiekty (metoda fabryczna) lub przekazuje obowiązek utworzenia obiektu do podklasy (fabryka abstrakcyjna). W obu przypadkach operacja tworzenia obiektu jest oddzielona od miejsca jego użycia. Klient nie m usi znać różnych implementacji interfejsu lub klasy. Wystarczy, że wie, której fabryki (metody fabrycznej lub fabryki abstrakcyjnej) należy użyć w celu otrzymania egzemplarza jednej z implementacji interfejsu. Klienci nie są sprzężeni z procesem tworzenia obiektów. Rozluźnienie powiązań następuje jako wynik zastosowania zasady odwrócenia zależności i niesie ze sobą wiele praktycznych korzyści, z których najważniejszą jest odłączenie klas z wysokiego poziom u abstrakcji od tych, które znajdują się na niższym poziomie. Umożliwia to zmienianie implementacji konkretnych klas bez wpływu na klienta, redukując powiązania między klasami i zwiększając elastyczność systemu. W zorzec Fabryka umożliwia odłączenie procesu tworzenia obiektów od podstawowego systemu przez zamknięcie kodu służącego do tworzenia obiektów w specjalnej fabryce. To znacznie ułatwia pracę programiście, gdy trzeba coś pozmieniać w kodzie, ponieważ istnieje jeden punkt, w którym mają miejsce te zmiany. Samą fabrykę często im plementuje się jako klasę singletonową lub statyczną, ponieważ zwykle potrzebny jest tylko jeden egzemplarz fabryki. Powoduje to centralizację procesu tworzenia obiektu fabryki, ułatwiając organizację struktury kodu i jego obsługę serwisową oraz zredukow anie liczby błędów występujących po w prowadzeniu zm ian i aktualizacji. UWAGA Zasada inwersji zależności: 1. Moduły znajdujące się na wysokim poziomie abstrakcji zależą od modułów położonych niżej. Jedne i drugie powinny zależeć od abstrakcji. 2. Abstrakcje nie powinny zależeć od szczegółów. Szczegóły powinny zależeć od abstrakcji1. W Javie EE rozluźnienie powiązań między klasami wyższego i niższego poziomu abstrakcji przy implem entowaniu wzorca Fabryka uzyskuje się przy użyciu wstrzykiwania zależności. Stosowanie kombinacji adnotacji @Produce rs i @ Inject ułatwia implementację.
Metoda Fabryczna W książce Bandy Czworga2 znajduje się następujący opis metody fabrycznej: „Definiuje interfejs do tworzenia obiektu, ale pozwala podklasom zdecydować, której klasy egzemplarz utworzyć”. W książce Wzorce projektowe. Rusz głową!3 dodano jeszcze, że „metoda fabryczna pozwala klasie oddelegować tworzenie egzemplarza do podklas”. 1 W ikipedia; http://en.w ikipedia.org/w iki/D ependency_inversion_principle. 2 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010. 3 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010.
Metoda Fabryczna
| 87
Fabryki minimalizują wykorzystanie słowa kluczowego new oraz mogą zawierać cały proces inicjacyjny i różne konkretne implementacje. Możliwość scentralizowania tych potrzeb sprowadza do minimum efekt dodania konkretnych klas do systemu lub usunięcia ich z niego oraz efekty zależności konkretnych klas. N a rysunku 6.1 przedstawiono diagram klas m etody fabrycznej. «interface» IProduct
product = creator.FactoryMethodl)
A
i j Clien t
product: IProduct
ProductA
ProductB
Creator
+FactoryMethod(): Product
Rysunek 6.1. Diagram klas ilustrujący strukturę wzorca projektowego Metoda Fabryczna. Widać na nim, że mechanizm tworzenia obiektu znajduje się w podklasach
OPOWIADANIE WOJENNE Kiedyś pisałem z kolegą aplikację desktopową. Początkowo nie byliśmy pewni, czy będzie nam potrzebna kompletna baza danych, czy też nie. Było to wiele lat przed pojawieniem się baz danych bez SQL i baz dokumentowych, więc jedyną alternatywą było użycie formatu XML. Nie wiedzieliśmy jednak, czy pliki XML wystarczą nam do przechowywania danych. Rozpoczęliśmy prace nad programem i potrzebowaliśmy konkretnej implementacji mechanizmu zapisującego dane. Jako że chcieliśmy zachować możliwość zmiany formatu XML na SQL, postanowiliśmy tworzyć wszystkie obiekty dostępu do danych (DAO) przez implementację wzorca Fabryka. Takie podejście powinno nam umożliwić łatwą zamianę XML na SQL i odwrotnie. Po kilku tygodniach wiedzieliśmy już, że znacznie zaniżaliśmy potrzeby systemu, jeśli chodzi o ilość danych. Tym samym format XML został wykluczony i pozostaliśmy do końca projektu z bazą danych typu SQL. W końcowym rozrachunku w ogóle nie używaliśmy naszej fabryki obiektów DAO. Kiedy jednak kończyliśmy aplikację, klienci poprosili o platformę demonstracyjną. Ale nie wystarczyło im zademonstrowanie funkcji programu i możliwość pobawienia się nim przez parę dni. Potrzebowali więcej czasu, aby go dobrze sprawdzić. W związku z tym musieliśmy zainstalować funkcjonującą aplikację w sieci, aby klienci mogli ją sobie przetestować i upewnić się, że działa tak jak powinna. Nie chcieliśmy instalować kompletnej aplikacji, ponieważ nie wiedzieliśmy, czy klient jej nie skopiuje, ale nie mieliśmy też ochoty budować od zera wersji demonstracyjnej. Wtedy wpadłem na doskonały pomysł. Aplikacja demonstracyjna powinna zapisywać dane, aby działać i aby klient mógł ją ocenić, ale nie na tyle dobrze, by dało się zrobić nielegalną kopię aplikacji. Mój pomysł polegał na tymczasowym przechowywaniu danych w pamięci. Gdyby udało się nam zmienić bazę danych na magazyn w pamięci, to klienci mogliby testować aplikację ile tylko by chcieli. (Bez trwałego magazynu danych aplikacja byłaby bezużyteczna!). Ponieważ mieliśmy już fabrykę obiektów DAO, wystarczyło tylko zaimplementować odpowiednie klasy „pamięciowe" i zmienić kod fabryki tak, aby zwracał je w przypadku niedostępności bazy danych.
88
I
ROZDZIAŁ 6. Wzorzec Fabryka
Efekt był na tyle zachęcający, że dodatkowo zaimplementowałem jeszcze jedną fabrykę, aby wersja demonstracyjna nie wysyłała zadań drukowania do drukarki, tylko do niesformatowanego pliku tekstowego. Dzięki tym zmianom bez obaw mogliśmy pozwolić klientom testować naszą aplikację do woli, ponieważ brak możliwości drukowania sformatowanych kopii i zapisywania danych finansowych w bazie danych sprawiał, że aplikacja stawała się bezużyteczna w środowisku produkcyjnym. Wykorzystanie fabryk w początkowym projekcie systemu nie było oszałamiającym sukcesem, ale uratowało nam życie później. Wzorce projektowe, jeśli są stosowane w odpowiednim kontekście, mogą pomagać w rozwiązywaniu przyszłych problemów.
Implementacja Metody Fabrycznej w zwykłym kodzie Implementacja M etody Fabrycznej nie zawiera szablonowego kodu. Na listingach od 6.1 do 6.6 przedstawiono implementację wzorca Fabryka w postaci klasy DrinksMachine dostarczającej różne rodzaje napojów w zależności od im plem entacji jej podklas. Listing 6.1. Abstrakcyjna klasa DrinksMachine rozszerzana przez konkretne implementacje public a b s tra c t c la ss DrinksMachine { public a b s tra c t Drink dispenseD rink(); public S trin g displayM essage() { return "Dziękuj ę ."; } } Listing 6.2. Implementacja CoffeMachine abstrakcyjnej klasy DrinksMachine public c la ss CoffeeMachine extends DrinksMachine { public Drink dispenseD rink() { return new C offee() ; } } Listing 6.3. Implementacja SoftDrinksMachine abstrakcyjnej klasy DrinksMachine public c la ss SoftDrinksMachine extends DrinksMachine { public Drink dispenseD rink() { return new SoftD rink() ; } } Listing 6.4. Interfejs Drink public in te rfa c e Drink {}
Fabryka Abstrakcyjna
| 89
Listing 6.5. Implementacja SoftDrink interfejsu Drink public c la ss SoftDrink implements Drink { SoftD rink() { System.out. println("N apój bezalkoholowy"); } } Listing 6.6. Implementacja Coffee interfejsu Drink public c la ss Coffee implements Drink { Coffee() { System .out.println("K aw a"); } } Implementacja ta ilustruje, jak podklasy abstrakcyjnej klasy DrinksMachine określają napój do dostarczenia. Pozwala to każdej implementacji klasy DrinksMachine na dostarczenie dowolnego obiektu typu Drink. Każda podklasa abstrakcyjnej klasy DrinksMachine określa, które napoje są dostarczane. Jest to prosta implementacja, w której m etoda d ispenseD rink dostarcza tylko jeden typ napoju. Ciekawszy byłby przykład, w którym metoda ta pobierałaby nazwę napoju oraz tworzyła i zwracała żądany obiekt. Na listingu 6.7 pokazano, jak to zrobić. Listing 6.7. Wyliczenie CoffeeType public enum CoffeeType { EXPRESSO, LATTE} public Drink dispenseDrink(CoffeeType type) { Drink coffee = n u ll; switch (type) { case EXPRESSO: coffee = new Expresso(); case LATTE: coffee = new L atte() ; } return coffee; } Dla uproszczenia w tym rozdziale pokazujemy tylko kod wyliczenia CoffeeType definiującego typ kawy i metodę dispen seD rin k konkretnej klasy Coffee.
Fabryka Abstrakcyjna Wzorzec Fabryka jest bardzo prosty i łatwy w implementacji, ale w złożonych systemach trzeba dobrze przemyśleć strukturę opartego na nim rozwiązania. W efekcie powstał nowy wzorzec projektowy o nazwie Fabryka Abstrakcyjna. W książkach Bandy Czworga i Wzorce projektowe. Rusz głową! został on opisany jako „interfejs do tworzenia rodzin spokrewnionych lub współzależnych obiektów bez określania ich konkretnych klas”.
90
I
ROZDZIAŁ 6. Wzorzec Fabryka
Innym i słowy: Fabryka Abstrakcyjna zawiera grupę fabryk i sprawuje kontrolę nad dostępem do nich przez klientów z zewnątrz. W tym rozdziale nie opisujemy wszystkich szczegółów dotyczących implementacji fabryk abstrakcyjnych, tylko przedstawiamy krótkie wprowadzenie, aby pokazać, o co w tym chodzi. N a rysunku 6.2 pokazano diagram klas wzorca Fabryka Abstrakcyjna.
Rysunek 6.2. Jak widać na diagramie, wzorca Fabryka Abstrakcyjna można używać do grupowania istniejących fabryk i kontrolowania sposobu dostępu do nich z zewnątrz
Implementacja Fabryki Abstrakcyjnej w zwykłym kodzie Sposób implementacji wzorca Fabryka Abstrakcyjna pokażemy na podstawie wcześniejszego przykładu autom atu do napojów. Dodamy do niego fabrykę produkującą dwa różne rodzaje maszyn — podstawową i dla smakoszy. „Rodziny spokrew nionych lub współzależnych obiektów ” tw orzone przez fabrykę abstrakcyjną to m aszyny z kawą i napojam i bezalkoholowym i. Trzeba utworzyć interfejs, który te fabryki będą im plem entow ać. N a listingu 6.8 widać im plem entację interfejsu 0 nazwie A b stra c tD rin k sM a c h in e F a cto ry . Listing 6.8. Interfejs dla fabryki abstrakcyjnej public in te rfa c e AbstractDrinksMachineFactory { public DrinksMachine createCoffeeM achine(); public DrinksMachine createSoftD rinksM achine(); } K onkretne im plem entacje tego interfejsu to klasy G ourm etD rinksM achineFactory 1 B asicD rin k sM ach in eF acto ry . Dla uproszczenia na listingu 6.9 przedstaw iam y tylko kod klasy G ourm etD rinksM achineFactory.
Implementacja wzorca Fabryka w Javie EE
| 91
Listing 6.9. Implementacja interfejsu AbstractDrinksMachineFactory public c la ss GourmetDrinksMachineFactory implements AbstractDrinksMachineFactory{ public DrinksMachine createCoffeeM achine() { return new GourmetCoffeeMachine() ; } public DrinksMachine createSoftDrinksM achine() { return new GourmetSoftDrinksMachine() ; } } Każda fabryka m a inną implementację metody fabryki abstrakcyjnej c re a te i w zależności od tego, której fabryki egzemplarz zostanie utworzony, otrzymuje się taką lub inną implementację maszyny z kawą lub napojam i bezalkoholowymi. AbstractDrinksMachineFactory facto ry = new GourmetDrinksMachineFactory(); DrinksMachine CoffeeMachine = factory.createC offeeM achine(); CoffeeMachine.dispenseDrink(CoffeeType.EXPRESSO); Jest to przykład tworzenia egzemplarza klasy GourmetDrinksMachineFactory. Wywołano jej metodę generującą maszyny z kawą w celu utworzenia obiektu tej maszyny, której potrzebuje ta implementacja. Cały kod tej implementacji znajduje się w plikach z kodem źródłowym do rozdziału 6.
Implementacja wzorca Fabryka w Javie EE Po poprzednich przykładach m ożna się zorientować, że implementacja wzorca Fabryka nie jest trudna. W Javie EE jest to znacznie uproszczone dzięki specjalnym adnotacjom i wstrzykiwaniu zależności. Do utworzenia obiektu służy adnotacja @Produces. Obiekt ten następnie można wstrzyknąć w odpowiednie miejsce za pomocą adnotacji @ Inject. Na listingu 6.10 ukazano najprostszą możliwą implementację wzorca M etoda Fabryczna w Javie EE. Listing 6.10. Prosta implementacja Metody Fabrycznej przy użyciu metod produkujących package com .devchronicles.producer; import ja v a x .e n te rp ris e .in je c t.P ro d u c e s; public c la ss EventProducer { @Produces public S tring getMessage() { return "W itaj, św iecie!" ; } } M etoda getM essage jest oznaczona adnotacją @Produces i zwraca obiekty łańcuchowe zawierające napis W ita j, ś w ie c ie ! Choć w tym przykładzie produkowane są obiekty typu łańcuchowego, w rzeczywistości m ożna zwracać, co się chce, np.: interfejsy, klasy, typy podstawowe, tablice Javy i rdzenne typy Javy.
92
| ROZDZIAŁ 6. Wzorzec Fabryka
Aby wykorzystać utworzony obiekt, należy wstrzyknąć taki sam typ do wybranej klasy, jak pokazano na listingu 6.11. Listing 6.11. Wstrzykiwanie łańcucha utworzonego przez fabrykę package com .devchronicles.factory; import import import import
ja v a x .e jb .S ta te le s s ; jav ax .e jb .T ra n sa c tio n A ttrib u te; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .in je c t.I n je c t;
@ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss EventService { @Inject p riv a te S trin g message; public void sta rtS e rv ic e () { S y stem .out.println("P oczątek wywołania usługi " + message); } } Gdy zostanie wywołana m etoda s ta r tS e r v ic e , następuje wstrzyknięcie wartości łańcuchowej z metody produkującej do składowej message klasy E ventS ervice i wydrukowanie jej w konsoli. Jest to najprostsza możliwa implementacja wzorca Fabryka w Javie EE. Budzi ona pewną poważną wątpliwość: skąd kontener CDI wie, że m a wstrzyknąć łańcuch wyprodukowany przez metodę getM essage do składowej message klasy E ventService? Kontener ten wykorzystuje typy do określania miejsca wstrzyknięcia wyprodukowanego typu. W tym przykładzie produkowany i wstrzykiwany jest typ łańcuchowy. Zatem kontener odkrywa, że są to dwa takie same typy, i dokonuje wstrzyknięcia. Ktoś może stwierdzić, że w prawdziwym systemie trzeba produkować i wstrzykiwać różne egzemplarze tego samego typu obiektu. Skąd kontener CDI wie, gdzie wstrzyknąć każdy z tych w yprodukow anych obiektów? W ykorzystuje w tym celu konfigurację adnotacji zwaną kw alifikatorem . W prawdziwych projektach raczej nie zwraca się prostych łańcuchów, tylko różne typy obiektów, aby tworzyć właśnie różne obiekty według typu. Listing 6.12. Ziarno MessageA package com .devchronicles.factory; @ Alternative public c la ss MessageA { p riv a te S tring message; public S tring getMessage() { return message; }
Implementacja wzorca Fabryka w Javie EE
I 93
public void setM essage(String message) { this.m essage = message; } } Listing 6.13. Ziarno MessageB package com .devchronicles.factory; @ Alternative public c la ss MessageB { p riv a te S tring message; public S tring getMessage(){ return message; } public void setM essage(String message){ this.m essage = message; } } Listing 6.14. Implementacja fabryki tworzącej ziarna wiadomości package com .devchronicles.factory; import ja v a x .e n te rp ris e .in je c t.P ro d u c e s; public c la ss EventProducer { @Produces public MessageA messageAFactory(){ return new MessageA(); } @Produces public MessageB messageBFactory(){ return new MessageB(); } } Utworzyliśmy dwa ziarna: MessageA na listingu 6.12 i MessageB na listingu 6.13. Dodaliśmy do nich adnotację @ A lternative, aby kontener ich nie znalazł i nie próbował wstrzykiwać ich egzemplarzy, gdy znajdzie pasujący punkt wstrzyknięcia. Egzemplarze będzie produkow ać implementacja fabryki przedstawiona na listingu 6.14. Gdybyśmy nie dodali adnotacji, kontener podczas ładow ania aplikacji zgłosiłby wyjątek o mniej więcej takiej treści: CDI deploym ent failure:W ELD-001409 Ambiguous d ep endencies f o r ty p e [MessageA] („Niepowodzenie wdrażania CDI:WELD-001409. Niejednoznaczne zależności dla typu [MessageA]”). Przyczyną tej niejednoznaczności są dwa egzemplarze klasy MessageA: jeden tworzony przez kontener i drugi przez metodę oznaczoną adnotacją @Produces. Kontener nie wie, który egzemplarz wstrzyknąć do składowej message klasy E ventService. Rozwiązanie tego problem u jest opisane w dalszej części rozdziału. Na listingu 6.15 przedstawiono implementację klasy E ventService.
94
| ROZDZIAŁ 6. Wzorzec Fabryka
Listing 6.15. Wstrzykiwanie ziaren utworzonych przez fabrykę przy użyciu adnotacji @Inject package com .devchronicles.factory; import import import import import
ja v a x .e jb .S ta te le s s ; jav ax .e jb .T ra n sa c tio n A ttrib u te; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .e n te rp rise.e v e n t.E v e n t; ja v a x .in je c t.I n je c t;
@ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss EventService { @Inject p riv a te MessageA messageA; @Inject p riv a te MessageB messageB; public void s ta rtS e rv ic e (){ messageA.setMessage("To je s t wiadomość A"); messageB.setMessage("To je s t wiadomość B"); S y stem .out.println("P oczątek wywołania S y stem .out.println("P oczątek wywołania
usługi " + messageA.getMessage()); usługi " + messageB.getMessage());
} } W pokazanej tu klasie E ventS ervice kontenery wstrzykują dwa ziarna wyprodukowane przez fabrykę do zmiennych składowych messageA i messageB klasy EventService. Obiektów tych można używać w norm alny sposób. Do oznaczania typów, które chce się wstrzyknąć, m ożna również użyć adnotacji @ Q ualifier i @ interface. W poniższym przykładzie przy użyciu niestandardowych adnotacji utworzono dwa kwalifikatory: @ShortMessage (listing 6.16) i @LongMessage (listing 6.17). Listing 6.16. Kwalifikator ShortMessage @ Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.METHOD, ElementType.FIELD} ) public @ interface ShortMessage {} Listing 6.17. Kwalifikator LongMessage @ Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.METHOD, ElementType.FIELD} ) public @ interface LongMessage {} Przy użyciu tych kwalifikatorów m ożna oznaczać m etody produkujące (listing 6.18) i ich punkty wstrzyknięcia (listing 6.19).
Implementacja wzorca Fabryka w Javie EE
| 95
Listing 6.18. Rozstrzyganie niejednoznaczności przy użyciu kwalifikatorów public c la ss EventProducer { @Produces @ShortMessage p riv a te MessageA messageAFactory() { return new MessageA() ; } @Produces @LongMessage p riv a te MessageB messageBFactory() { return new MessageB() ; } } Listing 6.19. Wstrzykiwanie utworzonych ziaren przy użyciu kwalifikatorów do rozstrzygania niejednoznaczności @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss ClientMessage { @Inject @ShortMessage p riv a te MessageA messageA; @Inject @LongMessage p riv a te MessageB messageB; public void doEvent(){ messageA.setMessage("To je s t długa wiadomość e -m a il."); messageB.setMessage("To je s t k ró tk i SMS."); System .out.println(m essageA .getM essage()); System .out.println(m essageB.getM essage()); } } Zdefiniowana w interfejsie kwalifikatora adnotacja @Target określa, gdzie m ożna używać tego kwalifikatora. Jej wartością może być dowolna liczba z tych wartości: TYPE, METHOD, FIELD oraz PARAMETER. Ich znaczenie jest oczywiste. Taką samą implementację m ożna też utworzyć przy użyciu typu wyliczeniowego zdefiniowanego w klasie ^ in te r f a c e , jak pokazano na listingu 6.20. Listing 6.20. Niestandardowy typ adnotacji @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.METHOD} ) public @ interface MyEvent { Type v a lu e (); enum Type{ LOGGING, MESSAGE } } Dzięki tej adnotacji można tworzyć obiekty łańcuchowe przy użyciu różnych metod oznaczonych tą adnotacją. Na listingu 6.21 łańcuchy są tw orzone przez m etody m essageAFactory i m essageBFactory.
96
I
ROZDZIAŁ 6. Wzorzec Fabryka
Listing 6.21. Rozróżnianie ziaren przy użyciu własnych adnotacji public c la ss EventProducer { @Produces @MyEvent(MyEvent.Type.LOGGING) public S tring messageAFactory(){ return "Wiadomość"; } @Produces @MyEvent(MyEvent.Type.MESSAGE) public S tring messageBFactory() { return "Inna wiadomość"; } } Przy użyciu tych adnotacji oznaczamy m etody produkujące i odpowiadające im punkty wstrzykiwania, jak pokazano na listingu 6.22. Listing 6.22. Wstrzykiwanie utworzonych ziaren, rozstrzygając niejednoznaczności przy użyciu własnych adnotacji package com .devchronicles.observer; import import import import import
ja v a x .e jb .S ta te le s s ; jav ax .e jb .T ra n sa c tio n A ttrib u te; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .e n te rp rise.e v e n t.E v e n t; ja v a x .in je c t.I n je c t;
@ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss EventService { @Inject @MyEvent(MyEvent.Type.LOGGING) p riv a te S trin g messageA; @Inject @MyEvent(MyEvent.Type.MESSAGE) p riv a te S trin g messageB; public void sta rtS e rv ic e () { S y stem .out.println("P oczątek wywołania usługi " + messageA); S y stem .out.println("P oczątek wywołania usługi " + messageB); } } Prostszym rozwiązaniem byłoby użycie adnotacji @Named zamiast tworzyć własną adnotację. N a listingu 6.23 pokazano, jak to zrobić. Listing 6.23. Wykorzystanie adnotacji @Named do rozstrzygania niejednoznaczności package com .devchronicles.factory; import ja v a x .e n te rp ris e .in je c t.P ro d u c e s; public c la ss EventProducer { @Produces
Implementacja wzorca Fabryka w Javie EE
| 97
@Named("Logging") public S tring messageAFactory() { return "Wiadomość"; } @Produces @Named("Message") public S tring messageBFactory(){ return "Inna wiadomość"; } } Za pom ocą adnotacji @Named oznaczamy m etody produkujące i odpowiadające im punkty wstrzyknięcia, jak pokazano na listingu 6.24. Listing 6.24. Wstrzykiwanie przy użyciu adnotacji @Named @ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss EventServiceName { @Inject @Named("Logging") p riv a te S tring messageA; @Inject @Named("Message") p riv a te S tring messageB; public void sta rtS e rv ic e () { S y stem .out.println("P oczątek wywołania usługi " + messageA); S y stem .out.println("P oczątek wywołania usługi " + messageB); } } Choć takie rozwiązanie wydaje się prostsze niż tworzenie własnego typu adnotacji, w skomplikowanych systemach może to nie być najlepsze lub bezpieczne dla typów wyjście. Nazwana adnotacja działa z łańcuchem w cudzysłowie i zdecydowanie nie jest bezpieczna pod względem typów. Kompilator nie może nas ostrzec przed potencjalnymi błędami.
Okiełznać moc kontenera CDI Jeśli aplikacja zawiera wiele implementacji interfejsu i chcemy zaimplementować fabrykę, aby produkować potrzebne egzemplarze obiektów, to utworzymy klasę fabryczną zawierającą wiele m etod oznaczonych adnotacją @Produces. Z czasem ilość kodu może być problematyczna. Na szczęście w Javie EE jest rozwiązanie w postaci adnotacji @Any i pomysłowego wykorzystania typów wyliczeniowych, literałów adnotacyjnych oraz klasy In sta n ce . Dzięki tem u do wyprodukowania każdego egzemplarza wystarczą cztery linijki kodu zamiast dziesiątek, a może nawet setek. W tym celu należy zebrać wszystkie egzemplarze określonej implementacji interfejsu i wybrać ten, którego chce się użyć za pomocą adnotacji @Any. Adnotacja @Any instruuje kontener, że wszystkie ziarna implementujące dany interfejs powinny być wstrzykiwane w określonym miejscu. Na poniższych listingach kod p riv a te Instance, messages wstrzykuje egzemplarze wszystkich zależności implementujących interfejs MessageType do zmiennej składowej messages.
98
I
ROZDZIAŁ 6. Wzorzec Fabryka
Po tym jak wszystkie zależności zostaną wstrzyknięte, trzeba je jakoś od siebie odróżnić i wybrać tę, która jest niezbędna. Do tego właśnie potrzebne są literały adnotacyjne i typy wyliczeniowe. N a poniższych listingach definiujemy kwalifikator @Message i literały wyliczeniowe SHORT i LONG. Służą one do rozróżniania implementacji interfejsu MessageType. Aby wybrać zależność, należy ją porównać z typem wyliczeniowym kwalifikatora każdej implementacji poprzez utworzenie literału A n n o ta tio n L ite ra l szukanego typu oraz pobrać ją i zwrócić do klienta. Poniżej przedstawiamy opisywaną implementację. Wykorzystujemy przykłady fabryki tworzącej obiekty typów ShortM essage i LongMessage, z których każdy im plem entuje interfejs Message i jest oznaczony adnotacją SHORT lub LONG. Listing 6.25. Interfejs MessageType public in te rfa c e MessageType { public S tring getMessage(); public void setM essage(String message); } Listing 6.26. Implementacja ShortMessage interfejsu wiadomości @Message(Message.T ype.SHORT) @Dependent public c la ss ShortMessage implements MessageType { p riv a te S tring message; @Override public S tring getMessage() { return message; } @Override public void setM essage(String message) { this.m essage = message; } } Listing 6.27. Implementacja LongMessage interfejsu wiadomości @Message(Message.Type.LONG) @Dependent public c la ss LongMessage implements MessageType { p riv a te S tring message; @Override public S tring getMessage() { return message; } @Override public void setM essage(String message) { this.m essage = message; } }
Implementacja wzorca Fabryka w Javie EE
I 99
Każda konkretna implementacja interfejsu MessageType, przedstawionego na listingu 6.25, jest oznaczona kwalifikatorem @Message określającym typ wiadomości Message.Type.SHORT lub M essage.Type. LONG — listingi 6.26 i 6.27. Kwalifikator @Message jest zaimplementowany w taki sam sposób jak kwalifikator użyty w pokazanym wcześniej przykładzie niestandardowego typu adnotacji — listing 6.28. Listing 6.28. Niestandardowa adnotacja wiadomości @Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ ElementType.FIELD, ElementType.TYPE} ) public @ interface Message { Type value() ; enum Type{ SHORT, LONG } } Aby utworzyć literał adnotacyjny służący do porównywania potrzebnego typu z typem zależności, należy rozszerzyć abstrakcyjną klasę A n n o ta tio n L ite ra l i zaimplementować Message jako niestandardowy kwalifikator wiadomości — listing 6.29. Listing 6.29. Literał adnotacyjny służący do pobierania potrzebnego typu wiadomości public c la ss M essageLiteral extends AnnotationLiteral implements Message { p riv a te s t a ti c f in a l long serialVersionUID = 1L; p riv a te Type type; public MessageLiteral(Type type) { th is .ty p e = type; } public Type value() { return type; } } Mamy wszystkie elementy układanki, więc możemy je złożyć w klasę M essageFactory pokazaną na listingu 6.30. Listing 6.30. Implementacja fabryki @Dependent public c la ss MessageFactory { @Inject @Any p riv a te Instance messages; public MessageType getMessage(Message.Type type) { M essageLiteral l i t e r a l = new M essageL iteral(type); Instance typeMessages = m e s s a g e s .s e le c t(lite ra l); return typeM essages.get() ; } }
100
I
ROZDZIAŁ 6. Wzorzec Fabryka
W klasie fabrycznej wszystkie zależności implementujące interfejs MessageType są wstrzykiwane do zmiennej składowej messages. Następnie w metodzie getMessage wykorzystujemy param etr Message.Type do utworzenia nowego obiektu typu M essageL iteral służącego do wyboru potrzebnej implementacji interfejsu MessageType, która jest zwracana do klienta. Klient wstrzykuje fabrykę i wywołuje metodę getM essage, przekazując wymagany param etr Message.Type, jak pokazano na listingu 6.31. Listing 6.31. Klient wykorzystujący implementację fabryki @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) @ApplicationScoped public c la ss C lient { @Inject MessageFactory mf; public void doMessage() { MessageType m = mf.getMessage(Message.Type.SHORT) ; m.setMessage("To je s t krótka wiadomość."); System .out.println(m .getM essage()) ; m = mf.getMessage(Message.Type.LONG); m.setMessage("To je s t długa wiadomość."); S y stem .out.println(m .getM essage()); } } W tym rozdziale trochę oddaliliśmy się od pierwotnej im plem entacji wzorca Fabryka przedstawionej w książce Bandy Czworga. Ktoś mógłby nawet powiedzieć, że to w ogóle nie jest implementacja tego wzorca projektowego, tylko wzorca wybierania i wstrzykiwania. Ale nowe dynamiczne funkcje kontenera CDI umożliwiają kreatywne implementowanie i udoskonalanie tradycyjnych wzorców.
Gdzie i kiedy używać wzorców fabrycznych Tradycyjna implementacja wzorca Fabryka znacznie się zmieniła w porów naniu z pierwszą wersją opisaną w książce Bandy Czworga. Fabryki abstrakcyjne są dobrym sposobem na ukrycie mechanizm ów tworzenia obiektów, w szczególności jeśli mechanizmy te są skomplikowane. Im bardziej złożony jest proces tworzenia obiektów, tym bardziej uzasadnione jest wykorzystanie fabryki. Jeżeli obiekty muszą być tworzone w spójny i ściśle kontrolowany sposób, to należy rozważyć możliwość zastosowania implementacji wzorca projektowego Fabryka. Z drugiej strony, pojawienie się środowiska CDI, w którym kontener zarządza tworzeniem obiektów, powoduje, że zasadność używania wzorca Fabryka jest dyskusyjna. Najlepszym sposobem implementacji tego wzorca jest użycie adnotacji @Produce, która pozwala ukryć skomplikowaną logikę tworzenia obiektu w metodzie produkującej i wstrzykiwać otrzymane obiekty do klienta.
Podsumowanie
| 101
M ożna również wykorzystać możliwości środowiska CDI, zlecając kontenerowi tworzenie obiektów i wybierając potrzebne egzemplarze z puli podobnych obiektów. Jednak ta technika nadaje się do zastosowania tylko w przypadku, gdy obiekty są proste i mogą być tworzone w satysfakcjonujący sposób przy użyciu konstruktora domyślnego.
Podsumowanie W tym rozdziale przedstawiliśmy sposób implementacji różnych rodzajów wzorca Fabryka w środowisku innym niż CDI. Jeśli zaś chodzi o środowisko CDI, pokazaliśmy, jak metody produkujące i adnotacja @ Inject radykalnie zmieniły sposób implementacji i zastosowania wzorca Fabryka w Javie EE. Pokazaliśmy, jak wykorzystać możliwości automatycznego tworzenia obiektów ziaren przez kontener oraz jak wybierać te ziarna w swoim kodzie. Nie chcemy pozostawiać jakichkolwiek wątpliwości, że im plementacja wzorca Fabryka w Javie EE jest bardzo eleganckim i prostym sposobem generowania obiektów.
ĆWICZENIA 1.
Utwórz fabrykę pojazdów produkującą różne typy samochodów osobowych i półciężarówek przy użyciu wzorca Fabryka Abstrakcyjna.
2.
Zaimplementuj tę samą fabrykę pojazdów co w poprzednim ćwiczeniu, ale przy użyciu adnotacji @Produce, kwalifikatorów oraz typów wyliczeniowych.
3.
Korzystając z kontenera CDI, zaimplementuj rozwiązanie pozwalające utworzyć wiele obiektów tego samego typu i wybierać potrzebny typ na podstawie logiki bezpiecznej typowo.
102 | ROZDZIAŁ 6. Wzorzec Fabryka
7 Wzorzec Dekorator
ZAWARTOŚĆ ROZDZIAŁU:_______ > jak zaimplementować wzorzec Dekorator w zwykłym kodzie; > jak wzorzec Dekorator rozwiązał pewien realny problem; > jak zaimplementować wzorzec Dekorator przy użyciu adnotacji @Decorator i @Delegate; > jak włączać i wyłączać dekoratory przy użyciu deskryptorów wdrożenia; > jak przy użyciu kwalifikatorów uzyskać precyzyjną kontrolę nad sposobem wykorzystania dekoratorów.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r07, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. W książce Bandy Czworga1 znajduje się następujący opis wzorca Dekorator: „Umożliwia dynamiczne dołączanie dodatkowych obowiązków do obiektu”, a jako przykład opisano zestaw narzędzi do tworzenia graficznych interfejsów użytkownika. Był to świetny wybór, ponieważ dodawanie nowych stylów i zachowań do zestawu narzędzi interfejsu użytkownika jest idealnym zadaniem dla wzorca Dekorator.
1 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010.
104
I
ROZDZIAŁ 7. Wzorzec Dekorator
W książce Wzorce projektowe. Rusz głową!2 opisano kawiarnię w ramach przykładu pozwalającego na wybór różnych dodatków, np. śmietanki, do produktu. Każdy dodatek powoduje opakowanie obiektu napoju oraz dodaje nowe zachowanie dla opisu i ceny. Przykład ten był najlepszym rozwiązaniem, ponieważ autorzy mieli podobne doświadczenia z własnej pracy zawodowej (zob. poniższe opowiadanie wojenne). Wzorzec projektowy D ekorator jest oparty na obiektach kom ponentu i obiektach dekoracyjnych implementujących ten sam interfejs. D ekorator zawiera zmienną egzemplarzową, która również implementuje ten interfejs, dzięki czemu może opakowywać zarówno obiekt kom ponentu, jak i inny dekorator. Posługiwanie się tym samym interfejsem pozwala dekoratorom na dekorowanie podstawowego składnika lub innego dekoratora. Jeśli implementacja jest dobrze napisana, to można łatwo wywołać wszystkie implementacje funkcji w kolejności od ostatniego dekoratora do wewnętrznego docelowego obiektu kom ponentu. W większości przypadków dostosowanie istniejącego systemu do wykorzystywania wzorca D ekorator nie jest trudne.
Czym jest wzorzec Dekorator Dekorator to jeden ze strukturalnych wzorców projektowych opisanych w książce Bandy Czworga. Jego celem jest opakowanie obiektu docelowego, aby móc do niego dynamicznie dodawać nowe funkcje. Każdy dekorator może opakowywać inny dekorator, co teoretycznie umożliwia dekorowanie obiektów docelowych nieskończoną liczbą dekoracji. Choć takie dynamiczne działanie jest znacznie bardziej elastyczne niż dziedziczenie oparte na klasach, wprowadza też dodatkowy poziom złożoności do tworzenia konkretnych podklas, ponieważ utrudnia określanie typów i zachowań obiektów przed uruchom ieniem aplikacji. Dekoratory są wykorzystywane w prawie wszystkich językach programowania i na wszystkich platformach, od interfejsów użytkownika po systemy zapleczowe. W większości systemów szkieletowych i wykonawczych wzorzec D ekorator zapewnia elastyczność oraz pozwala realizować czynności wykonywane tylko podczas działania program u. W Javie EE wzorzec Dekorator im plementuje się bez użycia szablonowego kodu. W odróżnieniu od większości pozostałych wzorców opisanych w tej książce dodaje się też kod konfiguracyjny do pliku bean.xml.
OPOWIADANIE WOJENNE Kilka lat temu podpisaliśmy umowę na kompletny system do obsługi zamówień i płatności dla branży gastronomicznej. Zamówiła go firma, która wówczas świadczyła usługi jako system obsługiwania punktów sprzedaży POS3. Do jej klientów należały restauracje, kawiarnie i bary. Niewiele wiedzieliśmy o tej branży, więc musieliśmy przyjąć parę założeń na podstawie posiadanych szczątkowych informacji. Na szczęście większość z tych założeń była trafna. Jedną z reguł projektowych, jakie przyjęliśmy, było to, że jeśli dodatek zmienia cenę produktu, to powinno się dodać nowy produkt. Jeżeli więc w restauracji podaje się powiększone porcje za dopłatą, do menu dodawana jest nowa pozycja. Jeżeli natomiast jakiś dodatek jest darmowy, np. dodatkowy ser, to informację tę zapisuje się tylko jako uwagę na marginesie zamówienia.
2 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010. 3 Pyro; http://m use.com .tr/pyro.htm l.
Czym jest wzorzec Dekorator
Wszystko działało bardzo dobrze do czasu, aż napotkaliśmy trochę nietypową kawiarnię. W przybytku tym głównie serwowano desery, ale jako pikantną przystawkę podawano też pizzę. Pizza była jedynym daniem głównym w całym menu. A ponieważ kawiarnia nie specjalizowała się w pizzy, nie było w niej ustalonego menu z różnymi rodzajami tego dania, tylko klient mógł stworzyć własną pizzę, wybierając z listy płatne dodatki. Jako że klienci rzadko zamawiali pizzę w tej kawiarni, takie rozwiązanie wydawało się całkiem rozsądne. Jednak dla naszego systemu oznaczało katastrofę. Winna była przyjęta przez nas zasada, że jeśli dodatek zmienia cenę produktu, to należy dodać do menu nowy produkt. Ze względu na to, że każdy dodatek miał inną cenę, musieliśmy obliczyć wszystkie kombinacje dodatków i dla każdej z nich dodać do menu nową pizzę. Jak wiadomo, algorytmy o złożoności obliczeniowej n! rosną bardzo szybko, czego efektem w tym przypadku byłaby bardzo długa lista pizz. To było nie do zaakceptowania, zaproponowaliśmy więc klientowi, aby stworzył kilka pizz z określoną liczbą dodatków (jeden, dwa, trzy), a następnie odnotowywał na zamówieniu, które dodatki wybrał klient. Pozwoliło nam to skrócić listę z n! do n. Ale to rozwiązanie nadal było niezadowalające. System już działał i był wykorzystywany, więc musieliśmy znaleźć sposób na poprawienie go tak, aby nie uszkodzić innych części. Szukaliśmy sposobu na dodawanie funkcji w czasie działania programu, czyli zastanawialiśmy się, jak „dekorować" obiekty pizzy dodatkami. Oczywiście rozwiązaniem była implementacja wzorca Dekorator. Każdy wybrany przez klienta dodatek opakowywał obiekt pizzy w podobny sposób jak opisano w przykładzie przedstawionym w książce Wzorce projektowe. Rusz głową!
Diagram klas wzorca Dekorator Jak widać na diagramie pokazanym na rysunku 7.1, wzorzec Dekorator wprowadza trochę szablonowego kodu do istniejącej hierarchii klas. Jest to wspólny interfejs klasy docelowej i dekoratora. Dekorator musi zawierać referencję do egzemplarza tego interfejsu.
Rysunek 7.1. Diagram klas wzorca Dekorator
| 105
106
I
ROZDZIAŁ 7. Wzorzec Dekorator
Implementacja wzorca Dekorator w zwykłym kodzie Jeśli klasy są dopiero projektowane, to dodanie dekoratorów nie powinno sprawiać większych problemów. Ale jeśli ktoś chce zaimplementować dekorator w istniejącym systemie, to może być zmuszony zmienić niektóre klasy. Na przykład klasa docelowa powinna implementować ten sam interfejs co dekorator. W tym rozdziale przedstawiamy zastosowanie wzorca Dekorator na podstawie uproszczonego systemu POS dla pizzerii. Każda pizza może zostać „udekorowana” dodatkami, np. podwójnym serem i darm ową papryczką chili. Zaczniemy od napisania interfejsu Order, który będzie im plem entowany przez klasę Pizza i przez abstrakcyjną klasę dekoratora Extra. Klasa Ext ra będzie rozszerzana przez klasy dodatków: DoubleExtra, NoCostExtra i R egularE xtra. Na listingu 7.1 znajduje się kod interfejsu Order. Listing 7.1. Interfejs Order public in te rfa c e Order { public double g e tP ric e (); public S tring getL abel(); } Na listingu 7.2 tworzymy klasę reprezentującą pizzę (cztery pory roku, margarita, hawajska itd.) w menu. Obiekty tej klasy będą celem dekoracji. Listing 7.2. Klasa, która ma być dekorowana, implementuje interfejs Order public c la ss Pizza implements Order { p riv a te S tring la b e l; p riv a te double p rice; public P izza(S tring la b e l, double p rice) { th is .la b e l= la b e l; th is .p ric e = p ric e ; } public double g etP rice() { return th is .p r ic e ; } public S tring getLabel() { return th i s .la b e l; } } Poniższe wyrażenie tworzy pizzę cztery pory roku. Order fourSeasonsPizza = new Pizza("Pizza Cztery pory roku" ,
10) ;
Implementacja wzorca Dekorator w zwykłym kodzie
I
107
Następnie należy utworzyć dekoratory, za pom ocą których będziemy dekorować pizzę dodatkami. Wykorzystamy klasę abstrakcyjną, dzięki czemu konkretne klasy nie będą musiały implementować wszystkich m etod biznesowych interfejsu. Abstrakcyjny dekorator będzie stanowił szablon do rozszerzania przez inne dekoratory. W ofercie restauracji znajdują się różne dodatki (ser, chili, ananas itd.). W yobraźmy sobie, że klient chce zamówić coś ostrzejszego, a restauracja za taki dodatek nie pobiera dodatkowej opłaty. W związku z tym potrzebujem y dekoratora, który nie zwiększa ceny pizzy, ale stosuje odpowiednie oznaczenie (że zamówiono więcej chili). Ponadto klient może zażyczyć sobie podwójnej porcji sera, ale jeśli system wydrukuje słowo „ser” dwa razy, to kucharz pomyśli, że to błąd, i da tylko jedną porcję sera. Potrzebny jest więc konkretny dekorator umożliwiający odpowiednie oznaczanie podwójnych porcji dodatków. Na listingu 7.3 znajduje się kod źródłowy opisywanego dekoratora abstrakcyjnego. Listing 7.3. Abstrakcyjny dekorator dodający dodatki public a b s tra c t c la ss Extra implements Order { protected Order order; protected S tring la b e l; protected double p rice; public E xtra(S tring la b e l, double p ric e , Order order) { th is .la b e l= la b e l; th is .p ric e = p ric e ; th is.o rd e r= o rd e r; } / / Cena m oże być problem atyczna, więc oddelegow ujem y to do konkretnej im plem entacji.
public a b s tra c t double g e tP ric e (); / / S tandardow y sposób oznaczania pow inien wystarczyć.
public S tring getLabel() { return ord er.g etL ab el()+ ", " + th is .la b e l; } } Mając abstrakcyjny dekorator, można dodać konkretne zachowania i utworzyć konkretne dekoratory. Zaczniemy od napisania dekoratora R egularE xtra, który dodaje opłatę i etykietę do obiektu docelowego (pizzy). Jako że funkcja etykietująca jest już zdefiniowana w dekoratorze abstrakcyjnym i dziedziczona przez wszystkie rozszerzające go podklasy, pozostało tylko zaimplementować funkcję dotyczącą ceny. Rozwiązanie przedstawiono na listingu 7.4. Listing 7.4. Dekorator dodający dodatki public c la ss RegularExtra extends Extra { public R egularE xtra(String la b e l, double p ric e , Order order) { su p e r(la b e l, p ric e , ord er); } public Double g etP rice() { return th is .p r ic e + o r d e r .g e tP r ic e ( ) ; } } W drugiej kolejności zdefiniujemy dekorator NoCostDecorator, w którym zmienimy łańcuch la b e l, ale nie zwiększymy ceny pizzy — listing 7.5.
108
I
ROZDZIAŁ 7. Wzorzec Dekorator
Listing 7.5. Dekorator dodający darmowy dodatek public c la ss NoCostExtra extends Extra { public NoCostExtra(String la b e l, double p rice , Order order) { su p e r(la b e l, p ric e , ord er); } public Double g etP rice() { return o rd e r.g e tP ric e (); } } I w końcu na listingu 7.6 znajduje się implementacja dekoratora DoubleExt ra potrzebna po to, by nie drukować dwa razy nazwy tego samego dodatku. Dekorator ten podwaja cenę i dodaje wyrażenie Dwa razy przed etykietą docelową. Listing 7.6. Dekorator dodający podwójne dodatki public c la ss DoubleExtra extends Extra { public DoubleExtra(String la b e l, double p rice , Order order) { su p e r(la b e l, p ric e , ord er); } public Double g etP rice() { return (th is .p ric e * 2 )+ o rd e r.g e tP ric e (); } public S tring getLabel() { return order.g etL ab el()+ ", Dwa razy " + th is .la b e l; } } Teraz możemy przetestować, jak nasza implementacja wzorca Dekorator obsługuje dodawanie dodatków do pizzy. Order fourSeasonsPizza = new Pizza("Pizza Cztery pory roku" , 10) ; fourSeasonsPizza = new RegularExtra("Pepperoni", 4, fourSeasonsPizza ); fourSeasonsPizza = new DoubleExtra("Mozzarella" , 2, fourSeasonsPizza ) ; fourSeasonsPizza = new NoCostExtra("Chili" , 2, fourSeasonsPizza ) ; S y ste m .o u t.p rin tln (fo u rS easo n sP izza.g etP rice()); S y stem .o u t.p rin tln (fo u rS easo n sP izza.g etL ab el()); W konsoli pojawi się następujący wynik: 18,0 Pizza, Pepperoni, Dwa razy M ozzarella, C h ili Ale w tym kodzie może być błąd! Papryka chili jest darmowa tylko jako dodatek do pizzy, ale jeśli ktoś zamówi ją sobie jako przystawkę, to musi za nią zapłacić. System powinien uwzględniać ten niuans. Wyobraź sobie, że te wszystkie wartości i etykiety pochodzą z bazy danych. Jak byś zrealizował różne zachowania dla chili? Jedną z możliwości jest utworzenie dwóch obiektów, z których jeden miałby etykietę „do pizzy”. Ta sztuczka jednak umożliwiałaby każdemu kelnerowi zamówienie darmowej papryczki chili dla znajomych. Inną możliwością jest utworzenie w klasie abstrakcyjnej dodatkowego konstruktora niepobierającego param etru ceny. Mógłby go implementować każdy dekorator niezwiększający ceny za dodatki.
Implementacja wzorca Dekorator w Javie EE
| 109
Implementacja wzorca Dekorator w Javie EE W odróżnieniu od większości pozostałych wzorców opisanych w tej książce wzorzec Dekorator implementuje się poprzez zadeklarowanie klas dekoracyjnych w deskryptorze wdrożenia bean.xml (wyjątkiem są klasy z adnotacją @ P rio rity — szczegóły znajdują się w podrozdziale „Dekoratory bez konfiguracji XML”). Na szczęście konfiguracja ta jest prosta, a jej zaletą jest możliwość włączania i wyłączania oraz kontrolowania kolejności wywoływania dekoratorów. Implementacja Dekoratora w Javie EE wprowadza dwie nowe adnotacje — @Deco ra to r i @Delegate. Adnotacja @Decorator służy do oznaczania klas dekoracyjnych, a @Delegate określa delegacyjny punkt wstrzyknięcia, w którym jest wstrzykiwana klasa do udekorowania. W ram ach przykładu przeanalizujemy system sklepu oferującego rabaty na niektóre ze swoich produktów. Do naliczania rabatu do normalnej ceny detalicznej będzie używany dekorator. Na listingu 7.7 znajduje się kod źródłowy interfejsu, którego będziemy używać do łączenia dekoratora z obiektem, który chcemy udekorować. Listing 7.7. Interfejs Product public in te rfa c e Product { public void setL ab el(S trin g la b e l); public void setP rice(d o u b le p ric e ); public S tring getL abel(); public double g e tP ric e (); public S tring generateL abel(); } Interfejs ten zawiera metodę generateL abel, którą dekorator powinien zaimplementować, aby dodać do obiektu funkcję naliczania rabatu. Na listingu 7.8 przedstawiono kod źródłowy klasy Table. Reprezentuje ona produkt, który będziemy chcieli udekorować, więc implementuje interfejs Product. Listing 7.8. Klasa do dekorowania implementuje interfejs Product public c la ss Table implements Product { p riv a te S tring la b e l = "Stół do ja d a ln i"; p riv a te double p rice = 100.00; public void setL ab el(S trin g la b e l) { t h i s .la b e l = la b e l; } public void setP rice(d o u b le p rice) { t h is .p r ic e = p rice; } public S tring getLabel() { return la b e l; } public double g etP rice() { return p rice; }
110
I
ROZDZIAŁ 7. Wzorzec Dekorator
public S tring generateLabel() { return p rice + " , " + la b e l; } } Klasa dekoracyjna P riceD isco u n tD eco rato r także musi implementować interfejs Product. Im plem entuje ona metodę g e n e ra te L a b e l i m echanizm naliczania rabatu. D ekorator ten redukuje cenę o 50% i dodaje do etykiety produktu napis (ra b a t). Aby kontener rozpoznał tę klasę jako dekorator, należy oznaczyć ją adnotacją @Decorator. Delegacyjny punkt wstrzyknięcia (egzem plarz, który zostanie udekorow any) jest oznaczony adnotacją @Delegate i m usi być polem wstrzykiwanym, param etrem m etody inicjacyjnej lub param etrem m etody konstrukcyjnej ziarna. Typ delegatu m usi być interfejsem zaim plem entow anym przez klasy, które chcemy dekorować — w tym przypadku Product. K ontener CDI wstrzykuje dostępny egzemplarz interfejsu P roduct do zmiennej składowej pro d u ct, jak pokazano na listingu 7.9. Listing 7.9. Dekorator PriceDiscountDecorator @Decorator public c la ss PriceDiscountDecorator implements Product { @Any @Inject @Delegate p riv a te Product product; public S tring generateLabel() { p ro d u c t.se tP ric e (p ro d u ct.g e tP ric e () * 0 .5 ); product.setL ab el(p ro d u ct.g etL ab el() + " (ra b a t)" ); return product.generateL abel() ; } / / niektóre m etody p o m in ięte dla uproszczenia
} N a koniec należy jeszcze zadeklarować dekorator w pliku bean.xml. Choć większą część konfiguracji wykonaliśmy już w adnotacjach, do działania dekoratora potrzeba jeszcze nieco kodu XML. Możesz być trochę zawiedziony, bo przecież już dodałeś odpowiednie adnotacje, ale ta konfiguracja jest prosta i służy do określenia kolejności wykonywania dekoratorów (jeśli jest więcej niż jeden). Dodaj do pliku bean.xml poniższy kod: < class> com .devchronicles.decorator.PriceD iscountD ecorator Praca skończona i można już używać dekoratora. @Any @Inject Product product; public void c re a te P ric e L ist() { S y stem .o u t.p rin tln ("E ty k ieta: " + product.g enerateL abel()); }
Implementacja wzorca Dekorator w Javle EE
I
111
Egzemplarz klasy Table zostaje wstrzyknięty do zmiennej składowej typu Product i następuje wywołanie m etody g en erateL ab el. W konsoli pojawi się następujący wynik: E tykieta: 12,5, S tó ł do ja d a ln i (rabat) Gdy zostaje wywołana m etoda g e n erateL ab el któregokolwiek egzemplarza typu Product, kontener przechwytuje to zdarzenie. Wywołanie zostaje oddelegowane do odpowiedniej metody dekoratora P riceD isco u n tD eco rato r, w którym oblicza się cenę z rabatem i przekazuje wywołanie do pierwotnego miejsca przeznaczenia za pom ocą wywołania m etody gen erateL ab el obiektu klasy Table. Łańcuch wywołań obejmuje wszystkie dekoratory, które zostały zadeklarowane do dekorowania klas implementujących interfejs Product. Kolejność wywołań dekoratorów jest zadeklarowana w deskryptorze wdrożenia bean.xml. N a listingu 7.10 przedstawiamy konkretny przykład, jak to działa. Tworzymy dekorator B lackFridayD iscountD ecorator, implem entujem y interfejs Product oraz dodajemy adnotacje @Decorator i @Delegate. Listing 7.10. Dekorator BlackFridayDiscountDecorator @Decorator public c la ss BlackFridayDiscountDecorator extends A bstractDiscountDecorator { @Any @Inject @Delegate p riv a te Product product; public S tring generateLabel() { p ro d u c t.se tP ric e (p ro d u ct.g e tP ric e () * 0.25); product. setL ab el(p ro d u ct.getL ab el()) ; return product.generateL abel() ; } / / niektóre m etody p o m in ięte dla uproszczenia
} Dekoratory należy dodać do archiwum bean.xml w takiej kolejności, w jakiej mają być wywoływane. W poniższym przykładzie deklarujemy, że dekorator P riceD isco u n tD eco rato r m a być wywołany przed dekoratorem B lackFridayD iscountD ecorator. com.d ev ch ro n icles.d e c o ra to r.PriceD iscountD ecorator com .devchronicles.decorator.B lackFridayD iscountD ecorator < /decorators> Gdy zostaje wywołana m etoda g en erateL ab el, powstaje łańcuch wywołań złożony z dwóch dekoratorów. Następuje przechwycenie wywołania m etody gen erateL ab el i oddelegowanie tego wywołania do metody g en erateL ab el klasy P riceD iscountD ecorator. M etoda ta wywołuje metodę g e tP ric e , a wywołanie to zostanie przechwycone i oddelegowane do m etody g e tP ric e obiektu klasy B lackF ridayD iscountD ecorator, która z kolei wywoła metodę g e tP ric e swojego wstrzykniętego obiektu typu Product. (Jest to ten sam egzemplarz, który wstrzyknęliśmy do dekoratora P riceD isco u n tD eco rato r). To wywołanie nie zostanie przechwycone, ponieważ nie m a już więcej dekoratorów dla tego interfejsu, i nastąpi wykonanie m etody g e tP ric e z obiektu klasy Table. Po zakończeniu jej działania następuje powrót przez stos wywołań do pierwszej
112
I
ROZDZIAŁ 7. Wzorzec Dekorator
m etody g e tP ric e . W ten sposób zostanie zwrócona cena obiektu Table. Dekorator zredukuje cenę o 50% i wywoła metodę s e tP ric e . To wywołanie zostanie oddelegowane przez łańcuch wywołań do obiektu klasy Table, w którym zostanie ustawiona nowa cena. Potem wywołanie wraca przez łańcuch wywołań. Zostaje wywołana metoda getL abel, tworząca łańcuch wywołań podobny do tego, który utworzyła m etoda g e tP ric e . Na końcu następuje wywołanie m etody g en erateL ab el, która zostaje przechwycona przez dekorator B lackFridayD iscountD ecorator. Cena zostaje zmniejszona o 25% i rozpoczyna się podobny łańcuch wywołań jak w przypadku dekoratora P riceD iscountD ecorator. W konsoli pojawi się następujący wynik: E tykieta: 6,25, S tó ł do ja d a ln i (rabat) Aby nie doszło do przerwania łańcucha, m etoda g e n erateL ab el musi delegować do metody g e n erateL ab el wstrzykniętego egzemplarza. W przeciwnym przypadku łańcuch zostanie przerwany i nastąpi wywołanie tylko pierwszego dekoratora. Dekoracji podlegają wszystkie klasy implementujące ten sam interfejs, który implementuje delegacyjny punkt wstrzykiwania, pod warunkiem że dekoratory są zadeklarowane w pliku bean.xml. Implikacje tego są następujące: ^
Dekoratory m ożna włączać i wyłączać w pliku bean.xml po wdrożeniu aplikacji. Umożliwia to elastyczne zarządzanie dekoratorami. Na przykład m ożna zaimplementować dekorator rabatowy, który będzie używany tylko przez czas trwania wyprzedaży, a potem go wyłączyć. W razie potrzeby wyłączony dekorator można potem włączyć, np. w celach diagnostycznych.
^
Dekorator jest automatycznie stosowany do klas implementujących ten sam interfejs. Jest to bardzo korzystne, gdy dodaje się nowe klasy, ponieważ nie trzeba pisać żadnego dodatkowego kodu związanego z dekorowaniem. Choć z drugiej strony, jeśli nie wszystkie klasy danego typu mają być dekorowane, może powstać problem. Można go jednak rozwiązać, oznaczając kwalifikatorami tylko te klasy, które mają być dekorowane.
Jeśli nie chcesz, aby wszystkie klasy określonego typu zostały udekorowane, musisz utworzyć własny kwalifikator oraz oznaczyć nim delegacyjny punkt wstrzykiwania i klasy, które chcesz dekorować. Utworzymy produkt P la te im plem entujący interfejs Product. Chcemy, aby rabat był naliczany tylko dla tego produktu. W celu realizacji tego wymogu oznaczymy go własnym kwalifikatorem, aby wykluczyć z dekoracji drugi produkt. Nasz kwalifikator nazwiemy @ ClearanceSale. @Qualifier @Retention(RUNTIME) @Target({FIELD, PARAMETER, TYPE}) public @ interface ClearanceSale {} Na listingu 7.11 tworzymy nową implementację interfejsu Product i oznaczamy ją naszym nowym kwalifikatorem. Listing 7.11. Klasa do udekorowania oznaczona niestandardowym kwalifikatorem @ClearanceSale public c la ss P late implements Product { p riv a te S tring la b e l = "Talerz"; p riv a te double p rice = 50.00;
Implementacja wzorca Dekorator w Javie EE
I
113
public void setL ab el(S trin g la b e l) { t h i s .la b e l = la b e l; } public void setP rice(d o u b le p rice) { t h is .p r ic e = p rice; } public S tring getLabel() { return la b e l; } public double g etP rice() { return p rice; } public S tring generateLabel() { return p rice + ", " + la b e l; } } Następnie oznaczamy delegacyjny punkt wstrzyknięcia w dekoratorze, który chcemy wywołać. W tym przypadku jest to dekorator P riceD isco u n tD ecorator. @ClearanceSale @Any @Inject @Delegate p riv a te Product product; W delegacyjnym punkcie wstrzyknięcia dekoratora PriceD iscountD ecorator zostaną wstrzyknięte tylko klasy oznaczone adnotacją @ ClearanceSale i implementujące interfejs Product. W efekcie dekoracja zostanie zastosowana tylko do klasy P la te . Delegacyjny punkt wstrzyknięcia może być oznaczony dowolną liczbą kwalifikatorów i wiąże się tylko z ziarnami opatrzonymi tym samym kwalifikatorem.
Dekoratory bez konfiguracji XML Podczas wdrażania aplikacji kontener CDI przeszukuje wszystkie jej pliki JAR i WAR w celu znalezienia deskryptorów wdrożenia bean.xml. Wszystkie, które znajdzie, przetwarza po kolei i wprowadza na ich podstawie odpowiednie ustawienia. Jeśli znajdzie deskryptor < d eco rato r/> , włącza dekoratory dla archiwum, w którym znajduje się zawierający go plik bean.xml. Nie włącza ich dla całej aplikacji. Jest to niedogodność w przypadkach, gdy program ista chce zastosować dekoratory do wszystkich klas implementujących dany interfejs niezależnie od tego, w którym miejscu aplikacji się znajdują. W CDI 1.14 wprowadzono możliwość włączania dekoratorów dla całej aplikacji poprzez oznaczenie klasy dekoracyjnej adnotacją @ P rio rity o wartości I n te r c e p t o r .P r i o r i t y . Poniżej pokazano, jak włączyć dwa opisane w tym podrozdziale dekoratory dla całej aplikacji. @ Priority(Interceptor.Priority.APPLICATION) @Decorator public c la ss PriceDiscountDecorator extends AbstractDiscountDecorator @ Priority(Interceptor.Priority.APPLICATION+10) @Decorator public c la ss BlackFridayDiscountDecorator extends AbstractD iscountD ecorator 4 Specyfikacja CD I 1.1; http://docs.jboss.org/cdi/spec/l.l/cdi-spec.htm l#decorators.
114
I
ROZDZIAŁ 7. Wzorzec Dekorator
Dekoratory z niższą wartością priorytetu są wywoływane wcześniej. W powyższym przykładzie dekorator P riceD iscountD ecorator zostanie wywołany przed dekoratorem B lackFridayD iscountD ecorator. Dekoratory oznaczone adnotacją @ P rio rity są wywoływane przed dekoratorami z deskryptora wdrożenia. Jeżeli dekorator jest włączony w obu miejscach, to zostanie wywołany dwa razy. Może to mieć niepożądany skutek, więc lepiej pilnować, aby dekoratory były włączane tylko w jeden sposób.
Gdzie i kiedy używać wzorca Dekorator W zorzec Dekorator dynamicznie dodaje funkcje do obiektów w czasie działania program u oraz wtedy, gdy nie da lub nie powinno się używać podklas (bo np. trzeba by było utworzyć bardzo dużo podklas). W przykładzie z pizzerią pokazano, jak dodawać funkcje do obiektu pizzy na podstawie wyborów dokonywanych przez klienta. Funkcjonalność interfejsu API m ożna rozszerzyć i poprawić, opakowując go w dekorator. W ten sposób często dekoruje się strumienie danych. Dobrym przykładem dekoratora opakowującego niskopoziomowy interfejs API i dodającego funkcjonalność buforowania strum ienia wejściowego jest strum ień j a v a .i o . B ufferedInputStream . W Javie EE dekoratory są zaim plem entow ane na podstawie CDI. Przy ich użyciu m ożna dodawać nowe funkcje biznesowe i inne, którym i m ożna opakować pierw otny obiekt. Taki projekt pow inien być dobrze udokum entow any i zaimplementowany, aby nie było problem ów z obsługą serwisową kodu. Możliwość włączania i wyłączania dekoratorów za pomocą deklaracji wpisywanych w deskryptorze wdrożenia ułatwia wielokrotne kompilowanie i wdrażanie aplikacji. W środowiskach, w których instaluje się m oduły na żywo, nie trzeba restartować serwera, aby wprowadzić zmiany dokonane w pliku bean.xml. Dzięki tem u bardzo łatwo m ożna zmienić działanie program u w środowisku produkcyjnym bez zatrzymywania usług. Kwalifikatory umożliwiają precyzyjniejszą kontrolę nad wykonywaniem dekoratorów niż włączanie i wyłączanie ich w deskryptorze wdrożenia bean.xml. Przy ich użyciu m ożna wykluczyć wybrane implementacje interfejsu z dekoracji albo zastosować różne dekoratory do implementacji tego samego interfejsu. Dekorator przechwytuje tylko wywołania do określonych typów Javy. Rozpoznaje całą semantykę interfejsu i może implementować logikę biznesową. Dzięki temu doskonale nadaje się do modelowania spraw biznesowych odnoszących się do określonego typu interfejsu. Dekoratory często porównuje się z interceptoram i, które przechwytują wywołania każdego typu Javy, ale nie rozpoznają semantyki, więc nie nadają się do modelowania spraw biznesowych. Interceptory służą do im plem entowania przekrojowych spraw, takich jak: rejestracja zdarzeń w dzienniku, zabezpieczenia i audyty, które nie są związane z logiką biznesową. Nadużywanie dekoratorów może prowadzić do powstawania błędów wykonawczych, generowania niezrozumiałego kodu źródłowego oraz utraty zalet ściśle typowanego polimorfizmu statycznego. Ponadto obecność dekoratorów może wymagać napisania dodatkowych przypadków testowych. Mimo to dekoratory zapewniają prawie nieograniczoną elastyczność i doskonały interfejs dla przyszłych implementacji pozwalający zmieniać program bez uszkadzania starego kodu.
Podsumowanie
| 115
Podsumowanie W tym rozdziale pokazaliśmy, że implementacja wzorca Dekorator w Javie EE wygląda prawie tak samo jak w starszej wersji Javy. Obiekt przeznaczony do udekorowania jest tworzony i wstrzykiwany przez kontener, a dekoratory, które mają zostać zastosowane, są wybierane na podstawie deklaracji zapisanych w deskryptorze wdrożenia bean.xml lub określane przy użyciu niestandardowych kwalifikatorów. Zastosowanie adnotacji i wstrzykiwania zależności pozwoliło zmniejszyć ilość kodu implementacji dekoratorów oraz ułatwiło wprowadzanie nowych klas, które są automatycznie dekorowane na podstawie implementowanego przez nie interfejsu. W yjaśniliśmy, że wzorzec D ekorator przekształcił się w coś w rodzaju systemu wtyczek, które można włączać i wyłączać podczas działania program u bez przerywania świadczenia usług. Ale jednocześnie wzorzec ten zachował swoje pierwotne przeznaczenie polegające na dodawaniu do obiektów funkcji i obowiązków.
ĆWICZENIA 1.
Rozwiń opisany wcześniej przykład sklepu, dodając do niego więcej dekoratorów rabatowych i wprowadzając nowe kwalifikatory zapewniające precyzyjniejszą kontrolę nad tym, które dekoratory mają być wywoływane dla konkretnych implementacji.
2.
Zaimplementuj wzorzec Dekorator, aby dodać nowe funkcje do istniejącego interfejsu API, np. java .io . File In p u tStre am .
3.
Utwórz dekorator dodający funkcję do systemu obsługującego konta bankowe powodującą, że jeśli klient pobierze z konta więcej niż określoną kwotę, na jego komórkę zostanie wysłana wiadomość SMS z powiadomieniem o transakcji.
116 | ROZDZIAŁ 7. Wzorzec Dekorator
8 Programowanie aspektowe (interceptory)
ZAWARTOŚĆ ROZDZIAŁU:_______ > wprowadzenie do programowania aspektowego; > aspekty w Javie; > stosowanie filtrów serwletów jako aspektów; > aspekty w Javie EE i interceptory; > interceptory EJB a interceptory CDI.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r08, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. Program ow anie aspektowe (ang. aspect-oriented programming — AOP) nie jest nowością. Techniki te m ożna stosować w Javie i w zewnętrznych systemach szkieletowych od początków m etod program owania aplikacji dla przedsiębiorstw. Mimo to AOP nie zostało uwzględnione jako jeden z klasycznych wzorców projektowych w książce Bandy Czworga1. AOP reprezentuje nową koncepcję program owania polegającą na określaniu kolejności wykonywania kodu na podstawie aspektów. Każdy aspekt przechwytuje wykonywanie program u i przed kontynuowaniem dodaje własne funkcje. 1 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010.
118
I
ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
Działanie aspektów może się wydawać magiczne, ponieważ dodają do działającego kodu logikę i funkcje. Niestety, skutkiem tego jest powstawanie niejednoznacznego i trudnego do zrozumienia przepływu sterowania oraz znacznie utrudniona diagnostyka. W efekcie techniki AOP mają zarówno zagorzałych zwolenników, jak i przeciwników. N a szczęście w Javie EE znajduje się elegancka i przejrzysta implementacja, która jeśli zostanie wykorzystana w odpowiedni sposób, może być bardzo przydatna.
Co to jest programowanie aspektowe Programowanie aspektowe (ang. aspect-oriented programming — AOP) to metodyka programowania umożliwiająca dodawanie funkcji do istniejącego kodu lub aplikacji w celu rozwiązania typowych problemów. Bardzo często się zdarza, że w trakcie prac nad programem pojawiają się nowe wymagania dotyczące rejestrowania zdarzeń lub zabezpieczeń. Refaktoryzacja kodu w celu ich spełnienia może wymagać ogromnego nakładu pracy, m imo że kod rejestrujący to tylko parę powtarzalnych linijek. Tego rodzaju sprawy, mogące pojawiać się zarówno w czasie programowania, jak i na etapie projektowania program u, nazywają się spraw am i przekrojow ym i (ang. cross-cutting concerns) i mogą być rozwiązywane przy użyciu technik AOP. Programowanie aspektowe zyskało popularność w ciągu ostatniej dekady. Choć w Javie nie było gotowego kompletnego rozwiązania w tym zakresie, oferowały je niektóre dobrze zaimplementowane zewnętrzne systemy szkieletowe. Należą do nich powszechnie znane i mające ugruntowaną pozycję wśród program istów systemy Spring i AspectJ. Podobne, choć znacznie bardziej ograniczone techniki dostępne były też w samej Javie pod postacią filtrów serwletów, chociaż ich zastosowanie ograniczało się do żądań sieciowych. Przy użyciu filtrów serwletów można przechwycić każde żądanie i każdą odpowiedź oraz dodać nowe funkcje. W Javie EE zaadaptowano techniki programowania aspektowego i wprowadzono pojęcie interceptora. W każdej kolejnej wersji technologii rozbudowywano tę funkcjonalność, aby w końcu zapewnić pełnię możliwości program owania aspektowego program istom tej platformy. AOP nie uważa się za wzorzec projektowy, lecz za metodykę programowania. Opisu aspektów nie m a ani w książce Bandy Czworga, ani w publikacji Wzorce projektowe. Rusz głową!2. Gdyby jednak było inaczej, to opis ten wyglądałby mniej więcej tak: „Zapewnia możliwość zmieniania sposobu wykonywania podczas działania (lub kompilacji) program u w celu rozwiązania przekrojowych spraw w istniejącym kodzie”. Techniki AOP opierają się na wstrzykiwaniu kodu podczas kompilacji lub wykonywania program u w celu dodania potrzebnych funkcji do każdego punktu w istniejącej bazie kodu, który to punkt spełnia określone warunki. Systemy szkieletowe dokonujące wstrzyknięć w czasie kompilacji z reguły odznaczają się dużą szybkością działania, ale wytwarzane przez nie pliki klas ze względu na wstrzyknięcia nie odpowiadają dokładnie kodowi źródłowemu. Natomiast wstrzykiwanie w czasie działania programu nie powoduje zmian w kodzie źródłowym ani w plikach klas i jest wykonywane przez przechwytywanie wywołań i urucham ianie żądanego kodu przed pierwotnym porządkiem wykonywania lub po nim. Techniki program owania aspektowego są pomocne, gdy trzeba dodać jakąś powtarzalną czynność, np. rejestracji lub zabezpieczenia czegoś, do bazy kodu. Aspekty można włączać i wyłączać w zależności od środowiska i fazy rozwoju projektu. Aspekty mogą dynamicznie dodawać funkcje do działającego kodu. Dynamicznie dekorują wywołania m etod, tak jak dekoratory dekorują obiekty. 2 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010.
Co to jest programowanie aspektowe
OPOWIADANIE WOJENNE Właśnie skończyliśmy prace nad aplikacją sieciową i przeprowadzaliśmy czynności przygotowawcze przed fazą wdrożenia programu do użytku. Po skończeniu testów funkcjonalności i akceptacji przez użytkowników mieliśmy przetestować zabezpieczenia aplikacji. Wynajęto zespół specjalistów od zabezpieczeń, którym zlecono sprawdzenie, czy w systemie znajdują się jakieś luki. Jako że poprzednia aplikacja została złamana i wykradziono z niej ważne informacje, klient przywiązywał do tej kwestii ogromną wagę. Byliśmy bardzo pewni swojego, więc kupiliśmy kilka toreb popcornu i przyglądaliśmy się testom. Po znacznej liczbie pomyślnych zakończeń pojawiła się jednak porażka. Specjalistom udało się przechwycić żądanie HTTP i zmienić niektóre parametry, aby otrzymać odpowiedź od aplikacji. Ale problem nie był poważny, ponieważ warstwa logiki biznesowej miała własny system autoryzacji. Niemniej jednak zmienione żądanie mogło umożliwić uzyskanie odpowiedzi przez kogoś, kto nie byłby uprawniony do jej otrzymania. Mówiąc krótko: klient musiał wywołać kilka usług, aby dostać się do zasobu. Powiedzmy, że usługa A zwraca identyfikatory, a usługę B można wywoływać przy użyciu identyfikatorów zwracanych przez usługę A. Analogicznie usługa C może być wywoływana przy użyciu jednego z identyfikatorów zwracanych przez usługę B. To oznaczało, że nieproszony gość mógł przechwycić i wprowadzić dowolny identyfikator usługi B, którą użytkownik mógł odpytać, ale tego nie zrobił. W takim przypadku klient obszedłby standardowy schemat wywołań i uzyskał dostęp do zasobu. Jako że zdobyte informacje były zasobem autoryzowanym przez użytkownika, szkoda była niewielka. Jednak zostało to zgłoszone jako błąd zabezpieczeń, który pozwalał na obejście normalnego schematu wykonywania. To zwróciło naszą uwagę. Aplikacja była już skończona i przetestowana i nie chcieliśmy nic w niej zmieniać. Wpadliśmy więc na doskonały pomysł: ponieważ w każdym żądaniu klient wykorzystywał identyfikator z poprzedniej odpowiedzi, mogliśmy przechwycić wszystkie zwracane identyfikatory. Jeżeli żądany identyfikator znajdował się na liście, mogliśmy zezwolić na dalsze działanie lub unieważnić sesję i zmusić użytkownika do ponownego zalogowania się. Pomysł był prosty i skuteczny, ale nie wiedzieliśmy, jak go wdrożyć przy minimalnym nakładzie pracy. Ponieważ wszystko, co chcieliśmy zrobić, miało związek z żądaniami sieciowymi, dobrym pomysłem wydawało się przechwytywanie i sprawdzanie poprawności tych żądań. Na szczęście w Javie wówczas było już wbudowane rozwiązanie, więc nie musieliśmy używać żadnego dziwacznego zewnętrznego systemu. Postanowiliśmy zaimplementować filtr serwletu. Jego zadaniem miało być buforowanie żądanych identyfikatorów w odpowiedzi i sprawdzanie, czy następne żądanie ma poprawny identyfikator z listy. Musieliśmy tylko dodać plik klasy pełniący funkcję filtru serwletu i włączającą go definicję XML. Rozwiązanie to można było bezproblemowo zastosować jako wtyczkę. Ponadto była możliwość jego wyłączenia w środowiskach testowych. System nie tylko zaliczył wszystkie testy bezpieczeństwa, ale dodatkowo przeszedł wszelkie oczekiwania. Z łatwością rejestrowaliśmy i wydobywaliśmy dane statystyczne z par żądanie-odpowiedź. A najlepsze było to, że nasze rozwiązanie nie wpłynęło na ogólną architekturę ani poziom złożoności systemu.
| 119
120
I
ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
Programowanie aspektowe jest doskonałym narzędziem do rozwiązywania niebiznesowych spraw. Jeśli jednak przy jego użyciu dodaje się funkcje do logiki biznesowej, może też wprowadzać sporo zamieszania. Implementacje takie powodują decentralizację logiki biznesowej, przez co znacznie trudniej się ją testuje i diagnozuje. W efekcie program jest trudniejszy w obsłudze serwisowej.
Implementacja AOP w zwykłym kodzie W Javie SE brak jest gotowego rozwiązania w zakresie AOP, ale m ożna używać systemów szkieletowych, takich jak Spring lub AspectJ. Systemy takie wykorzystywały konfiguracje oparte na XML-u, obecnie programowanie aspektowe m ożna stosować przy użyciu adnotacji. Implementacja i konfiguracja tych dwóch systemów wykraczają poza ram y tematyczne tej książki. W arto z nich korzystać, ponieważ są to wypróbowane i łatwe w użyciu rozwiązania stanowiące dobrą alternatywę dla implementacji w Javie EE. N atom iast w aplikacjach sieciowych Javy do przechwytywania żądań i odpowiedzi m ożna wykorzystywać serwlety, co jest podobne do tego, jak działają aspekty. Aby zaimplementować filtr serwletu, należy utworzyć nowy plik klasy i zaimplementować interfejs filtru serwletu. Następnie pisze się implementację m etody d o F i l t e r ( ), jak pokazano na listingu 8.1. Listing 8.1. Prosta implementacja filtru serwletu package c o m .d e v c h ro n ic le s .in te rc e p to r.filte r; import java.io.IO E xception; import ja v a .u til.A rra y L is t; import j a v a .u t i l .L i s t ; import import import import import import import import
ja v a x .s e r v le t.F ilte r ; ja v a x .s e r v le t.F ilte rC h a in ; ja v a x .s e r v le t.F ilterC o n fig ; ja v a x .se rv le t.S e rv letE x c e p tio n ; ja v a x .se rv le t.S e rv letR eq u e st; ja v a x .se rv le t.S e rv letR esp o n se ; ja v a x .s e r v le t.h ttp .H ttp S erv letR eq u est; ja v a x .s e r v le t.http.H ttpS ervletR esponse;
public c la ss S e c u rity F ilte r implements F i lt e r { @SuppressWarnings("unused") p riv a te F ilterC onfig filte rC o n fig = n u ll; @Override public void d o F ilter(S erv letR eq u est request, ServletResponse response, F ilterC hain filte rC h a in ) throws IOException, ServletException { L og.info(((H ttpServletR equest) re q u e st) . getRemoteAddr()); / / test bezpieczeństwa
} @Override public void in it(F ilte rC o n fig filte rC o n fig ) throws ServletException { th is .f ilte r C o n f ig = filte rC o n fig ; } }
Implementacja AOP w zwykłym kodzie
| 121
Do aktywowania filtru serwletu na danych adresach URL kontener sieciowy potrzebuje konfiguracji pokazanej na listingu 8.2. Należy ją wpisać w pliku web.xml aplikacji sieciowej. Listing 8.2. Definicja filtru serwletu < filte r> < filter-nam e> L ineS soFilter< /filter-nam e> < filte r -c la s s > c o m .d e v c h ro n ic le s .in te rc e p to r.filte r< /filte r-c la s s > < /f ilte r > < filter-n am e> S ecu rity F ilte r< /filter-nam e> /* < /filter-m apping> Implementacja filtrów Servlet 3.0 jest jeszcze łatwiejsza, bo m ożna używać adnotacji i nie trzeba pisać konfiguracji XML — listing 8.3. Listing 8.3. Prosta implementacja filtru serwletu napisana zgodnie ze specyfikacją Servlet 3.0 package c o m .d e v c h ro n ic le s .in te rc e p to r.filte r; import java.io.IO E xception; import ja v a .u til.A rra y L is t; import j a v a .u t i l .L i s t ; import import import import import
ja v a x .se rv le t.S e rv letE x c e p tio n ; ja v a x .se rv le t.S e rv letR eq u e st; ja v a x .se rv le t.S e rv letR esp o n se ; ja v a x .s e r v le t.h ttp .H ttp S erv letR eq u est; ja v a x .s e r v le t.http.H ttpS ervletR esponse;
import ja v a x .s e r v le t.F ilte r ; import ja v a x .se rv le t.an n o ta tio n .W e b F ilte r; import javax.servlet.annotation.W eblnitP aram ; @WebFilter(filterName = "TimeOfDayFilter", u rlP a tte rn s = {"/*"}) public c la ss S e c u rity F ilte r implements F i lt e r { @Override public void doFilter(S erv letR eq u est request, ServletResponse response, FilterC hain filte rC h a in ) throws IOException, ServletException { L og.info(((H ttpS ervletR equest) re q u e st) . getRemoteAddr()); / / test bezpieczeństwa
} }
122
I
ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
Filtry serwletów łatwo się implementuje, ale to nie znaczy, że ich możliwości są niewielkie — są tylko ograniczone do żądań sieciowych przesyłanych między klientem i serwerem. Aby przechwytywać inne wywołania metod albo dostosować przechwytywanie, należy zastosować bardziej zaawansowaną technikę.
Aspekty w Javie EE i interceptory W J2EE nie było gotowego rozwiązania w zakresie technik programowania aspektowego, ale m ożna było z powodzeniem używać zewnętrznych systemów szkieletowych. W Javie EE 5 wprowadzono interceptory, wraz z którymi pojawiło się łatwe w użyciu gotowe rozwiązanie aspektowe. Jednak do czasu wprowadzenia CDI interceptory były ograniczone do EJB. Interceptory w Javie EE działają podobnie do aspektów. Każdy interceptor dotyczy jakiejś sprawy i zawiera blok kodu reprezentujący funkcję, która m a zostać dodana. Obiekt dekoracji nazywa się radą (ang. advice). Każde odwołanie do rady występujące w zakresie interceptora jest przechwytywane. Miejsce wykonania aspektu nazywa się punktem przecięcia (ang. pointcut). Podstawowe interceptory Javy EE współpracują tylko z EJB. W yobraź sobie aplikację zawierającą kilkaset ziaren EJB. Można sprawić, aby rejestrowała wszystkie wywołania EJB, wdrażając interceptor dotyczący wszystkich tych ziaren. Implementacja interceptorów w Javie EE nie jest trudna. Najpierw należy utworzyć nową klasę interceptorową i oznaczyć ją adnotacją @ Interceptor. Klasa ta zawiera kod rady. Każda metoda oznaczona adnotacją @AroundInvoke będzie wykonana w punkcie przecięcia. Należy jednak pamiętać o pewnych zasadach dotyczących składni sygnatury takich metod: ^
Metoda przecięcia musi zwracać obiekt typu Object i mieć parametr typu InvocationC ontext.
^
M etoda może zgłaszać wyjątek.
Przy użyciu parametru InvocationContext można pobrać informacje o bieżącym kontekście — listing 8.4. Listing 8.4. Prosta implementacja interceptora package co m .devchronicles.interceptor; import javax.interceptor.A roundInvoke; import jav ax .in tercep to r.In v o catio n C o n tex t; @ Interceptor public c la ss S e c u rity In te rc ep to r { @AroundInvoke public Object doSecurityCheck(InvocationContext context) throws Exception{ / / Test bezpieczeństwa!
Logger.getLogger("SecurityLog") .info("D ostęp do " + context.getM ethod().getName()+ "!"); return context.proceed(); } } Aby włączyć klasę interceptorową do akcji, należy oznaczyć radę docelową adnotacją @ Interceptors, jak pokazano na listingu 8.5. Adnotacja ta może zostać wykorzystana tylko w EJB i MDB (ang. Message Driven Bean).
Aspekty w Javie EE i interceptory
I
123
Listing 8.5. Prosta implementacja rady docelowej
package co m .devchronicles.interceptor; import import import import import import
ja v a x .e jb .S ta te le s s ; jav ax .ejb .T ran sactio n A tt rib u te; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .e n te rp rise.e v e n t.E v e n t; ja v a x .in je c t.I n je c t; ja v a x .in te rc e p to r.In te rc e p to rs ;
@ In te rce p to rs(S e c u rity In te rc e p to r.c lass) @ Stateless @TransactionAttribute(TransactionAttributeType.REQUIRED) public c la ss SomeBusinessService { public void sta rtS e rv ic e (){ / / skom plikow ana logika biznesowa
Logger.getLogger("AppLog").in fo ("sk o ń czo n e..." ) ; } public void startA notherS ervice(){ / / skom plikow ana logika biznesowa
Logger.getLogger("AppLog").info("skończone drugi r a z ..." ) ; } } Adnotacja @ In tercep to rs jest elastyczna. M ożna ją stosować zarówno do klas, jak i metod. Ponadto obsługuje różne interceptory, co pozwala na stosowanie wielu interceptorów do jednej rady docelowej. Na listingu 8.5 użyto interceptorów na poziomie klasy, co oznacza, że interceptor zabezpieczeń przechwyci każde z wywołań usługi. Jeśli interceptor nie powinien przechwytywać wszystkich wywołań w klasie, m ożna zastosować adnotacje do metod, jak pokazano na listingu 8.6. Listing 8.6. Implementacja interceptorów klasowych package co m .devchronicles.interceptor; import import import import import import
ja v a x .e jb .S ta te le s s ; jav ax .e jb .T ra n sa c tio n A ttrib u te; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .e n te rp rise.e v e n t.E v e n t; ja v a x .in je c t.I n je c t; ja v a x .in te rc e p to r.In te rc e p to rs ;
@ Stateless @TransactionAttribute(TransactionAttributeType.REQUIRED) public c la ss SomeBusinessService { @ In te rce p to rs(S e c u rity In te rc e p to r.c lass) public void s ta rtS e rv ic e (){ / / skom plikow ana logika biznesowa
Logger.getLogger("AppLog").in fo ("sk o ń c z o n e ..."); } public void startA notherS ervice(){
124
I
ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
/ / skom plikow ana logika biznesowa
Logger.getLogger("AppLog").info("skończone drugi r a z ..." ) ; } } Tym razem, w odróżnieniu od listingu 8.5, przechwytywane są tylko wywołania metody s t a r t S e r v i c e ( ). Każdą metodę należy oznaczyć osobno. Adnotacje @ In tercep to r i @ In tercep to rs w połączeniu z @AroundInvoke to potężne narzędzia do rozwiązywania przekrojowych spraw w technikach programowania aspektowego. Ponadto interceptory zapewniają łatwą opartą na adnotacjach implementację, pozbawioną szablonowego kodu. Przy użyciu interfejsu In v o catio n C o n tex t m ożna pobierać informacje o kontekście lub współpracować z kontekstem rady. Poniżej znajduje się opis kilku najbardziej przydatnych metod. Metoda
Opis
public Object getTarget();
Zwraca do docelowej rady
public Method getMethod();
Zwraca wykonaną metodę z rady
public Object[] getParameters();
Pobiera parametry metody docelowej rady
public void setParameters(Object[]) ;
Ustawia parametry metody docelowej rady
public java.util.Map getContextData();
Pobiera dane kontekstowe
public Object proceed() throws Exception;
Kontynuuje wykonywanie
Na listingu 8.7 pobierana jest nazwa metody. Ponadto sprawdzamy, czy interceptor wcześniej autoryzował dostęp. Jeśli nie, możemy autoryzować użytkownika dla tej metody. Listing 8.7. Pobieranie informacji z InvocationContext package com .devchronicles.interceptor; import javax.interceptor.AroundInvoke; import javax.interceptor.InvocationContext; @Interceptor public class SecurityInterceptor { @AroundInvoke public Object doSecurityCheck(InvocationContext context) throws Exception{ / / testy bezpieczeństwa
Logger.getLogger("SecurityLog").info("Dostęp do " + context.getMethod().getName()+ "!"); String user = context.getContextD ata.get("user"); i f (user==null){ user=(String)context.getParam eters()[0]; context.getContextData.put("user", u ser)' } return context.proceed(); } }
Aspekty w Javie EE i interceptory
| 125
Cykl życia interceptora Fazy cyklu życia interceptorów można łatwo przechwycić przy użyciu specjalnych adnotacji. W odróżnieniu od technik rozszerzania i przesłaniania, zastosowanie adnotacji powoduje podłączenie funkcji do odpowiednich faz. Dostępne są adnotacje: @ PostConstruct, @ PrePassivate, @ PostActivate oraz @PreDestroy. Na listingu 8.8 przedstawiono przykład użycia niektórych z nich. Listing 8.8. Podłączanie faz cyklu życia interceptora package co m .devchronicles.interceptor; import jav ax.interceptor.A roundlnvoke; import jav ax .in tercep to r.In v o catio n C o n tex t; @ Interceptor public c la ss S e c u rity In te rc ep to r { @AroundInvoke public Object doSecurityCheck(InvocationContext context) throws Exception{ / / test bezpieczeństwa
Logger.getLogger("Security Log").info("D ostęp do " + ^context.getM ethod( ) . getName()+ "!"); S tring user = co n tex t.g etC o n tex tD ata.g et("user"); i f (user==null){ user= (S trin g )co n tex t.g etP aram eters()[0 ]; context.getC o n tex tD ata.p u t("u ser", u se r)' } return context.proceed(); } @PostConstruct public void o n S tart(){ Logger.getL ogger("SecurityL og").info("A ctivating"); } @PreDestroy public void onShutdown(){ Logger.getL ogger("SecurityL og").info("D eactivating"); } } Ponieważ zaczepy są oparte na adnotacjach, nazwy m etod nie mają znaczenia.
Interceptory na poziomie domyślnym Oznaczenie docelowej rady adnotacją interceptorową zapewnia łatwą implementację i konfigurację, ale techniki AOP z reguły wymagają czegoś więcej. W większości przypadków interceptor musi wykonywać swoje działania w odniesieniu do wszystkich rad. W yobraź sobie interceptory dla dziennika lub zabezpieczeń — przyjęcie za cel tylko podzbioru ziaren EJB nie zdałoby egzaminu. Poza tym oznaczanie adnotacją każdego ziarna może być kłopotliwe i prowadzić do pomyłek. W Javie EE dostępne są interceptory poziomu domyślnego dotyczące wszystkich ziaren EJB lub tych, których nazwy odpowiadają określonemu schematowi. W odróżnieniu od poprzedniego przykładu, do implementacji interceptorów domyślnego poziom u potrzebna jest konfiguracja XML:
126
| ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
< e jb - ja r .. .> < interceptors> < interceptor> < in terc e p to r-c la ss> co m .devchronicles.S ecurityInterceptor < /in te rc e p to r-c la ss> < /in tercep to r> < /in tercep to rs> * < in terc e p to r-c la ss> < in terc e p to r-c la ss> co m .devchronicles.S ecurityInterceptor < /in te rc e p to r-c la ss> < /in te rc e p to r-c la ss> < /in tercep to r-b in d in g > < /e jb -ja r> Pierwsza część pliku EJB-JAR zawiera listę interceptorów, po której znajdują się deklaracje powiązań interceptorów. Powiązania definiuje się w części opisu zestawu, w której do deklarowania powiązań między interceptoram i i ziarnam i EJB m ożna używać symbolu wieloznacznego (*) mającego zastosowanie do wszystkich lub wybranych nazw. Kolejność interceptorów na liście decyduje o kolejności ich wykonywania. Interceptory wymienione w pliku EJB-JAR mają zastosowanie tylko do ziaren EJB z tego samego modułu.
Kolejność interceptorów Jeśli dla rady zdefiniowano więcej niż jeden interceptor, to wykonywane są one od najbardziej ogólnego do najbardziej specyficznego. Oznacza to, że interceptory domyślnego poziomu zostaną wykonane przed interceptoram i klasowymi, po których z kolei będą wykonane interceptory poziomu metod. Kolejność pod tym względem jest oczywista, ale uporządkowanie interceptorów tego samego poziom u to już całkiem inna historia. Jeśli jest więcej niż jeden interceptor domyślnego poziomu, to o kolejności wykonywania decyduje miejsce na liście definicji w pliku EJB-JAR. < e jb - ja r .. .> < interceptors> < interceptor> < in terc e p to r-c la ss> co m .devchronicles.S ecurityInterceptor < /in te rc e p to r-c la ss> < in terc e p to r-c la ss> com .devchronicles.A notherInterceptor < /in te rc e p to r-c la ss> < /in tercep to r> < /in tercep to rs> OrderBean < interceptor-order> < in terc e p to r-c la ss> co m .d evchronicles.S ecurityInterceptor
Aspekty w Javie EE i interceptory
I
< /in te rc e p to r-c la ss> < /in tercep to r-o rd er> < in terc e p to r-c la ss> com .devchronicles.A notherInterceptor < /in te rc e p to r-c la ss> < /in tercep to r-b in d in g > < /e jb -ja r> Jeżeli jest więcej niż jeden interceptor klasowy, to o kolejności wykonania decyduje miejsce na liście w adnotacji @ In tercep to rs. @ In te rce p to rs(S e c u rity In te rc e p to r.c lass, A n o th erIn tercep to r.class) @ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss SomeBusinessService { public void s ta rtS e rv ic e (){ / / . ..
Jeżeli jest więcej niż jeden interceptor na poziomie metody, to kolejność interceptorów jest taka sama jak w adnotacji @ Interceptors: @ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss SomeBusinessService { @ In te rce p to rs(S e c u rity In te rc e p to r.c la s s , A n otherIn tercep to r.class) public void s ta rtS e rv ic e (){ //...
Jeśli trzeba zmienić domyślną kolejność, m ożna to zrobić przez dodanie własnej konfiguracji do pliku XML EJB-JAR. W poniższym przykładzie zmieniono kolejność interceptorów według własnego uznania. < e jb - j a r ... > < interceptors> < interceptor> < in terc e p to r-c la ss> co m .d evchronicles.S ecurityInterceptor < /in te rc e p to r-c la ss> < /in tercep to r> < /in tercep to rs> OrderBean < interceptor-order> < in terc e p to r-c la ss> co m .d evchronicles.S ecurityInterceptor < /in te rc e p to r-c la ss> < /in tercep to r-o rd er> < in terc e p to r-c la ss> com .devchronicles.A notherInterceptor < /in te rc e p to r-c la ss> sta rtSe rvice < /in tercep to r-b in d in g > < /e jb -ja r>
127
128
| ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
W nielicznych przypadkach konieczne jest wyłączenie interceptorów. Do celu tego m ożna wykorzystać adnotacje, jak pokazano na listingu 8.9. W Javie EE dostępne są dwie takie adnotacje — do wyłączania interceptorów poziom u domyślnego i interceptorów klasowych. Listing 8.9. Wyłączanie interceptorów package com .devchronicles.in te rc e p to r; import import import import import import
ja v a x .e jb .S ta te le s s ; jav ax .e jb .T ra n sa c tio n A ttrib u te; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .e n te rp rise.e v e n t.E v e n t; ja v a x .in je c t.I n je c t; jav ax .in te r c e p to r .I n te r c e p to r s ;
@ ExcludeDefaultInterceptors @ ExcludeClassInterceptors @ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss SomeBusinessService { public void s ta rtS e rv ic e (){ / / skom plikow ana logika biznesowa
Logger.getLogger("A ppLog").info("skończone..."); } public void startA notherS ervice(){ / / skom plikow ana logika biznesowa
Logger.getLogger("AppLog").info("skończone drugi r a z ..." ) ; } } Przedstawiony powyżej przykład jest poprawny tylko dla EJB i MDB, co w wielu przypadkach może być niewystarczające. Na szczęście dzięki CDI nie stanowi to wielkiego problemu.
Interceptory CDI Przed wejściem do użytku CDI interceptorów można było używać tylko z ziarnami EJB i MDB. Kontener CDI znacznie rozszerzył możliwości programisty i zamienił interceptory w element technologii program owania aspektowego działający na każdym obiekcie. Implementacja interceptorów CDI jest łatwa i dość elastyczna. Najpierw należy zdefiniować powiązanie, którym jest własna adnotacja oznaczona adnotacją @ InterceptorB inding. @InterceptorBinding @Target({TYPE, METHOD}) @Retention(RUNTIME) public @ interface Secure {} Adnotacja @ InterceptorB inding służy do wiązania interceptorów z kodem docelowym. Następnie przy użyciu własnej adnotacji oznacza się zaim plem entow any interceptor. Interceptory CDI implementuje się tak samo jak EJB. Jedyna różnica polega na użyciu adnotacji wiązania widocznej na listingu 8.10.
Aspekty w Javie EE i interceptory
| 129
Listing 8.10. Wiązanie interceptora przy użyciu adnotacji @Secure
package co m .devchronicles.interceptor; import javax.interceptor.A roundInvoke; import jav ax .in tercep to r.In v o catio n C o n tex t; @Secure @ Interceptor public c la ss S e c u rity In te rc ep to r { @AroundInvoke public Object doSecurityCheck(InvocationContext context) throws Exception{ / / testy bezpieczeństwa
Logger.getLogger("SecurityLog").info("D ostęp do " + ^context.getM ethod( ) . getName()+ "!"); S tring user = co n tex t.g etC o n tex tD ata.g et("user"); i f (user == null){ user = (S trin g )c o n te x t.g e tP a ram ete rs()[0 ]; context.getC o n tex tD ata.p u t("u ser", u se r)' } return context.proceed(); } @PostConst ruct public void o n S tart(){ Logger.getLogger("SecurityLog").info("A ktyw acja"); } @PreDestroy public void onShutdown(){ Logger.getLogger("SecurityLog").info("D ezaktyw acja"); } } Podobnie jak w interceptorach EJB za pom ocą adnotacji @ In tercep to rs deklarujemy plik klasy dla interceptora. Adnotacja @Secure wiąże interceptor. N atomiast adnotacja @AroundInvoke oznacza metodę do wykonania podczas przechwyconych wywołań. Następnym krokiem jest zaimplementowanie adnotacji na radzie, jak pokazano na listingu 8.11. Listing 8.11. Implementacja @Secure na radzie package co m .devchronicles.interceptor; import ja v a x .in te rc e p to r.In te rc e p to rs ; @Secure public c la ss SomeBusinessBean { public void s ta rtS e rv ic e (){ / / skom plikow ana logika biznesowa
Logger.getLogger("AppLog").in fo ("sk o ń c z o n e ..."); }
130
I
ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
public void startA notherS ervice(){ / / skom plikow ana logika biznesowa
Logger.getLogger("AppLog").info("skończone drugi r a z ..." ) ; } } Interceptory C D I wymagają jednego dodatkowego kroku, polegającego na zadeklarowaniu ich w pliku bean.xml. To jeden z rzadkich przypadków, kiedy konieczne jest wykorzystanie konfiguracji XML. Konfiguracja ta określa kolejność wykonywania interceptorów. W iązania interceptorów mogą zawierać inne wiązania interceptorów opakowujących wiele wiązań. Jeśli nie m a pliku bean.xml, kontener CDI nie zadziała. < interceptors> c o m .d ev ch ro n icles.in tercep to r.S ecu rity In tercep to r< /class> com .devchronicles.interceptor.Som eO therInterceptor< /class> < /in tercep to rs> Choć kolejność deklaracji adnotacji wiązań może nasuwać myśl o kolejności wykonywania, w rzeczywistości nie m a ona znaczenia. Kolejność wykonywania interceptorów zależy od deklaracji w pliku bean.xml. Pomieszanie interceptorów CDI i EJB może stwarzać niejednoznaczności, jeśli chodzi o uporządkowanie. Zasadniczo interceptory EJB są wykonywane przed interceptoram i CDI. Przechwytywanie m etod wprowadza do kodu dodatkowe komplikacje, ale jeśli ktoś utworzy wiele powiązań oraz pomiesza interceptory CDI z interceptoram i EJB, to wzniesie się na wyższy stopień złożoności. Skomplikowane struktury interceptorowe mogą sprawiać problem y programistom, którzy nie są zaznajomieni z kodem aplikacji.
Gdzie i kiedy używać interceptorów Programowanie aspektowe to popularna metodyka programowania ułatwiająca implementowanie i realizowanie przekrojowych spraw. W niektórych sytuacjach jest doskonałym rozwiązaniem. Jej zastosowanie szczególnie warto rozważyć, gdy trzeba rejestrować zdarzenia, przeprowadzić audyt, wyeliminować luki w zabezpieczeniach, i w wielu innych niebiznesowych przypadkach. W Javie EE interceptory są potężnym i narzędziam i umożliwiającymi stosowanie technik program ow ania aspektowego bez wykorzystywania zewnętrznych systemów szkieletowych. Od wprowadzenia interceptorów CDI technologia Java EE stała się bardziej kom pletna i wszechstronna. Do zaim plem entow ania interceptora może być potrzebne trochę kodu konfiguracyjnego XML, co odróżnia tę technikę od innych wzorców opisanych w tej książce. Jednak konfiguracja ta m a na celu tylko określenie pewnej kolejności, co może być potrzebne także w innych wzorcach, np. Dekoratorze.
Podsumowanie
| 131
Za pom ocą interceptorów m ożna elegancko rozwiązywać wiele przekrojowych spraw. Z drugiej strony, interceptory zmieniające logikę biznesową mogą też sprawiać problemy, ponieważ logika ta zostaje rozdzielona między klasę i interceptor. M etoda biznesowa staje się nieczytelna i myląca, ponieważ nie widać w niej całości logiki. Ponadto to tylko niepotrzebnie komplikuje architekturę i sposób działania aplikacji. Co więcej, diagnozowanie błędów staje się prawie niemożliwe i bardzo skomplikowane. Kod powinien być czytelny, a jego zastosowanie powinno być oczywiste. N atomiast niepotrzebne wprowadzenie logiki biznesowej do interceptorów może spowodować wielkie szkody. Z drugiej strony, implementacja logiki niebiznesowej i powtarzalnych czynności w interceptorach pozwala uprościć m etody biznesowe. Z zasady należy unikać wykorzystywania interceptorów do wstrzykiwania logiki biznesowej lub zmieniania sposobu wykonywania program u. Interceptory są doskonałym rozwiązaniem, gdy trzeba wykonać jakieś powtarzalne czynności dotyczące metod lub klas.
Podsumowanie Programowanie aspektowe to popularna technika programowania, która m a zarówno gorących zwolenników, jak i zagorzałych wrogów. Oczywiście nie jest rozwiązaniem wszystkich problemów. Nieprawidłowo stosowane aspekty mogą pogorszyć czytelność kodu i skomplikować ogólny sposób działania aplikacji. Z drugiej strony, aspekty to też niemal magiczne narzędzia pozwalające zaimplementować przy m inim alnym nakładzie pracy dodatkową logikę dla istniejącego kodu. Łatwo się je włącza i wyłącza w zależności od środowiska wykonawczego. Na przykład aspekt rejestrujący zdarzenia można wyłączyć w środowisku programistycznym i włączyć w środowisku testowym. Java EE zapewnia proste interceptory obsługujące adnotacje i wymagające nieznacznej ilości konfiguracyjnego kodu XML. Interceptorów tych m ożna używać zarówno w kontekście EJB, jak i MDB na poziomie klas i metod. M ożna też deklarować interceptory na poziomie domyślnym, który dotyczy wszystkich ziaren EJB spełniających określone kryteria. Domyślny poziom i kolejność wykonywania interceptorów należy skonfigurować w pliku XML EJB-JAR. CDI znacznie rozszerza funkcjonalność interceptorów i je uelastycznia. Interceptory CDI są łatwe w konfiguracji i można ich łatwo używać poprzez adnotację @ InterceptorB inding. Przy użyciu wiązań interceptorów m ożna opakowywać inne wiązania interceptorów, tworząc w ten sposób łańcuchy interceptorów do wykonania. Kontener CDI potrzebuje paru linijek konfiguracyjnego kodu XML do określenia kolejności wykonywania. Interceptory EJB i CDI m ogą pracować osobno lub razem. Zapewniają wszystkie funkcje potrzebne do stosowania technik program ow ania aspektowego bez potrzeby stosowania zewnętrznych systemów szkieletowych. Jeśli interceptory są prawidłowo zastosowane, powstaje pięknie skonstruowana aplikacja o magicznym przepływie sterowania. Decydując się na wykorzystanie interceptorów, pamiętaj, że nie powinny zmieniać logiki biznesowej ani zawierać logiki aplikacji.
132
I
ROZDZIAŁ 8. Programowanie aspektowe (interceptory)
9 Asynchroniczność
ZAWARTOŚĆ ROZDZIAŁU:_______ > wprowadzenie do programowania asynchronicznego; > programowanie asynchroniczne; > programowanie asynchroniczne przy użyciu wątków; > wykorzystanie technik programowania asynchronicznego w ziarnach; > programowanie asynchroniczne w serwletach; > kiedy i gdzie stosować techniki programowania asynchronicznego.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r09, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. Choć program ow anie asynchroniczne nie zawsze wymienia się wśród wzorców projektowych, w ostatnim dziesięcioleciu asynchroniczne m etody programowania stały się bardzo popularne. Model program owania asynchronicznego jest oparty na wielowątkowości i wykonywaniu funkcji w wydzielonych wątkach. Z technik program ow ania asynchronicznego korzystają nie tylko wielowątkowe środowiska i języki programowania, ale również jednowątkowe platformy, takie jak choćby popularny system szkieletowy JavaScript o nazwie NodeJS.
134
I
ROZDZIAŁ 9. Asynchroniczność
UWAGA Programowanie asynchroniczne nazywa się też nieblokującym wykonywaniem metod, ponieważ w technice tej wywołanie metody nie powoduje zablokowania elementu, który ją wywołał. W Javie od początku znajdują się wbudowane mechanizmy pozwalające na wykorzystanie wielu wątków wykonawczych. Zapomniano natomiast o prostym systemie do wykonywania asynchronicznych wywołań. Pierwszą próbą zmiany tej sytuacji było dodanie w Javie 5 interfejsu futu re, który jednak okazał się niewygodny i trudny w obsłudze. W późniejszych wersjach platformy dodano adnotację @Asynchronous. Asynchroniczny serwlet zapewniał już znacznie lepszy zestaw narzędzi do programowania asynchronicznego.
Co to jest programowanie asynchroniczne Programowanie asynchroniczne to specjalny i zintegrowany przypadek wykorzystania wielowątkowości. Ze względu na naturę wątków modele wielowątkowe z reguły wymagają zastosowania systemów powiadomień i używania szablonowego kodu do inicjowania wątków. W ywołania asynchroniczne są stosowane nawet w jednowątkowych środowiskach, takich jak np. NodeJS. Prawie wszystkie systemy szkieletowe do budowy interfejsów użytkownika wykorzystują asynchroniczność po to, by zapewnić interaktywność elementów. Pierwsza litera w nazwie technologii Ajax1, stanowiącej fundam ent Web 2.0, także oznacza asynchroniczność. Techniki program owania asynchronicznego są przydatne także poza interfejsami użytkownika, najczęściej w program ach działających na serwerze. Jednak ani w J2SE, ani w J2EE nie było łatwej w użyciu implementacji tej metodyki. Dopiero w Javie 5 wprowadzono system współbieżności (ang. Concurrency Framework) na podstawie specyfikacji JSR 166. Specyfikacja ta zawiera opis wielu narzędzi w ogóle umożliwiających programowanie asynchroniczne oraz je ułatwiających. Także interfejs Future jest jednym z tych elementów, które ułatwiły program istom implementowanie asynchronicznego wykonywania metod. Ponadto system szkieletowy Spring udostępnia możliwość asynchronicznego wywoływania metod przy użyciu adnotacji. W Javie EE takie wygodne rozwiązanie jest dostępne dopiero w wersji 6.0. W Javie EE 6 wprowadzono adnotację ^Asynchronous oraz m echanizmy umożliwiające łatwe implementowanie asynchronicznego wywoływania metod.
Wzorzec Asynchroniczność Programowania asynchronicznego nie m a na liście wzorców projektowych w książce Bandy Czworga2 ani Wzorce projektowe. Rusz głową!3, ale gdyby było, to jego opis wyglądałby mniej więcej tak: „Pozwala na wykonywanie m etod bez blokowania tego, kto je wywołał”. Cechą charakterystyczną wywołań metod jest blokowanie wywołującego do czasu zakończenia ich wykonywania. To oczywiste i każdy się tego spodziewa, choć nie zawsze jest to pożądane. Prawie wszystkie systemy szkieletowe i platform y sieciowe wykorzystują żądania nieblokujące. 1 Jessie Jam es G arret, A jax: A N e w A pproach to W eb A pplications, http://w w w .adaptivepath.com /ideas/ajax-new -approach-w eb-applications/. 2 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010. 3 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010.
Co to jest programowanie asynchroniczne
| 135
OPOWIADANIE WOJENNE Polecono mi stworzenie portalu sieciowego do obsługi klientów pewnej firmy z branży telekomunikacyjnej. W ramach pracy nad tym projektem zaimplementowaliśmy szczegółową infrastrukturę rejestrowania zdarzeń. Aby zapewnić szybkie i niezawodne rejestrowanie informacji, postanowiliśmy nie korzystać z bazy danych. W ten sposób stworzyliśmy niezawodny system o krótkim czasie reakcji. Efekt pracy bardzo nam się podobał. Potem poproszono nas o rejestrowanie w tabeli bazy danych wszystkich działań użytkowników i niektórych dotyczących ich informacji. Baza danych, której kazano nam użyć, była znana z powolnego działania i częstego ulegania awariom, które wymuszały jej restartowanie. To była zła wiadomość dla naszego szybkiego i niezawodnego systemu rejestrującego. Musieliśmy go zmodyfikować, uwzględniając zawodność bazy danych. Wyobraź sobie, co by było, gdyby w czasie rejestrowania czynności wykonywanej przez użytkownika nastąpiła awaria bazy danych. Synchroniczne wywołanie systemu rejestrującego zablokowałoby odpowiedź dla użytkownika do czasu odzyskania połączenia lub przeterminowania żądania. Użytkownik musiałby długo czekać, co było nie do przyjęcia. Nie chcieliśmy zmuszać użytkownika do czekania na odpowiedź od bazy danych ani wyświetlać informacji o błędach tej bazy w interfejsie, zwłaszcza że rejestrowaliśmy tylko dane statystyczne. Po zaimplementowaniu i przetestowaniu wszystkich klas DAO dodaliśmy adnotację @Asynchronous i przygotowaliśmy się do wdrożenia systemu. Jak zwykle byliśmy pewni naszego dobrze przetestowanego pakietu wdrożeniowego, więc postanowiliśmy pójść do domu zamiast towarzyszyć całą noc administratorom przy wdrażaniu. Rano odebraliśmy e-mail z informacją, że aplikacja działa. Ale wkrótce w dziennikach serwera zaczęty masowo pojawiać się wiadomości o błędach informujące o braku połączenia z bazą danych. Skontaktowaliśmy się z administratorami serwera, którzy, jak się okazało, zapomnieli utworzyć w bazie danych tabele dla dziennika. Niedopatrzenie szybko zlikwidowano i wszystko szło dobrze do czasu, gdy pojawiły się problemy z wydajnością bazy danych i coraz częściej zaczęły występować restarty (czego można się było spodziewać, biorąc pod uwagę reputację tej bazy). Naszej aplikacji kilka razy nie udało się zapisać pewnych nieistotnych informacji, ale nigdy nie miała ona problemów z wydajnością. Jeśli wystąpił jakiś problem z bazą danych, przez który nie udało się czegoś zarejestrować, to użytkownik nawet tego nie zauważał. Było to możliwe dzięki asynchronicznemu wywoływaniu funkcji rejestrowania. Programowanie asynchroniczne to świetne rozwiązanie, gdy trzeba rozdzielić zadania, które nie muszą wchodzić ze sobą w interakcje. Asynchroniczność polega na wykonywaniu operacji równolegle lub w sposób nieblokujący wątku wykonawczego i odebraniu jej wyniku, gdy jest gotowy. Najczęściej do realizacji technik asynchroniczności wykorzystuje się wykonywanie równoległe. Nie da się tego dokładnie przedstawić przy użyciu diagramu klas, dlatego użyjemy diagramu przepływu sterowania. Na rysunku 9.1 pokazano kilka przepływów wykonywania asynchronicznego.
136
I
ROZDZIAŁ 9. Asynchroniczność
Przepływ asynchroniczny
Klasyczny asynchroniczny przepływ żądania i odpowiedzi Rysunek 9.1. Diagram przepływu asynchronicznego
Implementacja asynchroniczności w zwykłym kodzie Wątki, za pom ocą których łatwo m ożna wykonywać asynchroniczny kod, są dostępne w Javie od samego początku: public class AsyncRunnable implements Runnable { public void run() { System.out.println("Działa!"); } } Aby wykonać klasę typu Runnable, należy utworzyć jej egzemplarz i wywołać metodę run przez wywołanie m etody s t a r t ( ) na nowo utworzonym wątku: (new Thread(new AsyncRunnable())).start(); Choć jest to preferowany sposób urucham iania procesu wątku, m ożna też rozszerzyć klasę wątków i przesłonić metodę run(): public class AsyncThread extends Thread { public void run() { System.out.println("Działam!"); } } Następnie należy utworzyć egzemplarz swojej klasy i wywołać metodę s t a r t ( ) : (new HelloThread()).start(); Dwie najważniejsze metody wykorzystywane do pracy z wątkami to sle ep( ) i join ( ) . Obie w razie awarii zgłaszają wyjątek InterruptedException. M etoda sl ee p( ) usypia wątek na określoną liczbę milisekund. Na przykład poniższe wyrażenie usypia wątek na jedną sekundę: Thread.sleep(1000);
Implementacja asynchroniczności w zwykłym kodzie
I
137
M etoda j oi n( ) nakazuje wątkowi poczekać na zakończenie wykonywania innego wątku. W yobraź sobie, że jeden wątek, t 1 , do działania potrzebuje zasobu wytwarzanego przez inny wątek, t 2 . Aby zmusić pierwszy wątek do poczekania na zakończenie działania przez drugi wątek, należy go z nim połączyć w sposób pokazany poniżej: t 2. j oi n( ) ; Jedna z najpowszechniej stosowanych i znanych technik program ow ania asynchronicznego w Javie polega na wykorzystaniu interfejsu Future. Programista używa obiektu pośredniego zapewniającego referencję do przyszłego obiektu. Ponieważ w systemie współbieżności brak jest adnotacji do asynchronicznego wykonywania kodu, interfejs Future najczęściej wykorzystuje się w połączeniu z należącym do tego systemu interfejsem ExecutorService. Poniżej znajduje się przykład użycia usługi wykonawczej (ang. executor service) do wykonania zadania i zwrócenia referencji do interfejsu Future o odpowiednim typie ogólnym. ExecutorService executor = Executors.newSingleThreadExecutor(); Future reference = executor.submit( new Callable() { public String c al l( ) { return "Cześć!"; } } ); //...
i f (reference.isDone()) System.out.println(reference.get()); Klasa FutureTask jest implementacją interfejsu Future im plementującą interfejs Runnable, a więc jej obiekty m ożna wykonywać bezpośrednio: FutureTask reference = new FutureTask( new Callable() { public String c al l( ) { return "Cześć!"; } } ); executor.execute(reference); W ykonywanie m ożna anulować za pom ocą metody cancel(boolean maylnterruptIfRunning). Jeśli parametr maylnterruptIfRunning ma wartość true, to metoda SessionContext .wasCancelled() zwraca wartość true. W przeciwnym razie metoda ta oczywiście zwraca f a l s e . To, czy operacja została anulowana, m ożna sprawdzić za pomocą metody isCancelled ( ) , która zwraca wartość t rue, jeżeli zadanie zostało anulowane. System współbieżności opisany w dokumencie JSR 133 zawiera wiele narzędzi przydatnych w program owaniu współbieżnym i wielowątkowym, np. kolejki blokujące BlockingQueue, ale ich opis wykraczałby poza ramy tematyczne tego rozdziału. Zainteresowani czytelnicy mogą sięgnąć do książki Java. Współbieżność dla praktyków4. Ponadto do technik programowania równoległego i asynchronicznego wiele wniosło wprowadzenie w Javie 7 systemu szkieletowego Fork/Join.
4 B rian G oetz, T im Peierls, Joshua Bloch, Joseph Bow beer, D avid H olm es, D o u g Lea, Java. W spółbieżność dla p raktyków , H elion, 2007.
138
I
ROZDZIAŁ 9. Asynchroniczność
Programowanie asynchroniczne w Javie EE Efektem braku w J2EE wbudowanej obsługi asynchronicznych technik program ow ania (z wyjątkiem klasy Timer) było wpasowanie się w tę lukę zewnętrznych systemów szkieletowych, takich jak Spring i Quartz. Te braki uzupełniono w Javie EE 5, w której w końcu pojawił się standardow y m odel program ow ania asynchronicznego.
Asynchroniczne ziarna W Javie EE m ożna stosować techniki program owania asynchronicznego na kilka sposobów. Najprościej jest zaimplementować wzorzec asynchroniczny przy użyciu adnotacji. Wystarczy oznaczyć metodę adnotacją @Asynchronous, aby kontener wykonał ją asynchronicznie w osobnym wątku wykonawczym. Aby zobaczyć, jak adnotacja ta działa w praktyce, można ją dodać do przykładu singletonowego ziarna rejestrującego zdarzenia z rozdziału 4., „Wzorzec Singleton”. Na listingu 9.1 pokazano przykład asynchronicznego ziarna. Listing 9.1. Przykład asynchronicznego ziarna package com.devchronicles.asynchronous; import import import import import
javax.annotation.PostConst ruct; javax.ejb.Singleton; javax.ejb.Startup; java.util.logging.Logger; javax.ejb.Asynchronous;
@Startup @Singleton public class MyLoggingBean { private Logger logger; @PostConst ruct public void st art () { logger = Logger.getLogger("MyGlobalLogger"); logger.info("Byłem pierwszy!!!"); } public void logInfo(String msg){ logger.info(msg); } @Asynchronous public void logAsync(String msg){ logger.info(msg); } } M etoda logAsync() , w odróżnieniu od swojej odpowiedniczki l o g I n f o ( ) , jest wykonywana asynchronicznie. M ożna się o tym przekonać, dodając do kodu wywołania m etody Th read. s l e e p ( ) :
Programowanie asynchroniczne w Javie EE I
139
public void logInfo(String msg) { logger.info("Wersja synchroniczna"); try { Thread. sleep(1000); } catch (InterruptedException e) {} logger.info(msg); } @Asynchronous public void logAsync(String msg { logger.info("Wersja asynchroniczna"); try { Thread.sleep(13000); } catch (InterruptedException e) {} logger.info(msg); } Następnie należy utworzyć nowe ziarno, aby wywołać obie funkcje, jak pokazano na listingu 9.2. Listing 9.2. Dodanie dwóch funkcji do kodu z listingu 9.1 package com.devchronicles.asynchronous; import javax.annotation.PostConst ruct; import javax.ejb.Singleton; import javax.ejb.Startup; @Startup @Singleton public class TestLogging { @EJB MyLoggingBean logBean; @PostConst ruct public void testLoggers(){ System.out.println("Wywołanie asynchroniczne"); logBean.logAsync("Rej estrowanie asynchroniczne"); System.out.println("Wywołanie synchroniczne"); logBean.logInfo("Rejestrowanie synchroniczne"); System.out.println("koniec"); } } W konsoli powinien pojawić się następujący wynik: > Wywołanie asynchroniczne > Wersja asynchroniczna > Wywołanie synchroniczne
140
I
ROZDZIAŁ 9. Asynchroniczność
> Wersja synchroniczna > Rejestrowanie synchroniczne > koniec > Rejestrowanie asynchroniczne Po wykonaniu m etody te st Logge rs( ) następują wywołania m etod logAsync () i l ogSync (). Obie metody usypiają swój wątek wykonawczy na określony czas. W wynikach wyświetlonych w konsoli widać, że m etoda async() została wywołana i na długo przeszła w stan uśpienia, ale nie zablokowała wykonywania metody sync ( ) . M etoda sync () śpi przez pewien czas, ale zwraca sterowanie do metody, która ją wywołała, i drukuje napis koniec. Potem budzi się metoda async(), która kończy cały proces wydrukowaniem w konsoli napisu Rejestrowanie asynchroniczne. Z tego przykładu jasno wynika, że wywołania asynchroniczne nie powodują zatrzymania wątku wywołującego ani nie zawieszają wykonywania m etody sync ( ) . Kiedy jednak m etoda sync () przechodzi w tryb uśpienia, metoda, która ją wywołała, czeka, aż się obudzi. Przy użyciu adnotacji ^Asynchronous łatwo implementuje się asynchroniczne operacje, poza tym m ożna ją dodać do dowolnej metody w każdej chwili — zarówno podczas tworzenia program u, jak i już po jego ukończeniu.
Asynchroniczne serwlety W iadom o już, że każda m etoda ziarna może być asynchroniczna, jeśli tego zechcemy. Teraz dowiesz się jeszcze, jak się tworzy asynchroniczne serwlety. Gdyby nie było takiej możliwości, programiści mieliby wiele problemów ze spełnieniem wymogów stawianych nowoczesnym stronom internetowym. W specyfikacji Servlet 3.0 (JSR 315) wprowadzono pozytywne zmiany w interfejsach programowania aplikacji sieciowych (API). W końcu dodano obsługę asynchronicznego modelu wykonywania, uproszczono procedury konfiguracji, dodano możliwość stosowania systemu wtyczkowego i wprowadzono wiele drobniejszych udoskonaleń. Działanie asynchronicznych serwletów opiera się na pewnym udoskonaleniu protokołu HTTP 1.1 (ang. Hypertext Transfer Protocol), które umożliwiło nawiązywanie trwałych połączeń. W HTTP 1.0 w pojedynczym połączeniu m ożna przesłać tylko jedną parę żądanie-odpowiedź. Natomiast w HTTP 1.1 umożliwiono utrzymywanie połączenia z aplikacją przez dłuższy czas oraz wysyłanie wielu żądań. W standardowej implementacji system zapleczowy w Javie musiałby na stałe powiązać osobny wątek wykonawczy z połączeniem HTTP. Natom iast interfejsy API NIO (ang. nonblocking I/O — nieblokujące wejście i wyjście) wielokrotnie wykorzystują te same wątki do obsługi aktywnych żądań. Wszystkie serwery sieciowe spełniające wymogi specyfikacji Servlet 3.0 obsługują Javę NIO. Ale do czego to się może przydać? Systemy zapleczowe charakteryzują się tym, że zazwyczaj wykonuje się w nich czasochłonne operacje, takie jak: łączenie się z innymi serwerami, przeprowadzanie skomplikowanych obliczeń i transakcyjne przetwarzanie informacji w bazach danych. Natomiast cechy charakterystyczne stron internetowych stanowią przeciwieństwo tego, co robi się w systemach zaplecza. Użytkownicy oczekują krótkiego czasu reakcji i działania interfejsu nawet wtedy, gdy wykonywane są operacje na zapleczu. Rozwiązaniem tych problem ów okazała się technologia Ajax, której pojawienie się wyznacza początek rewolucji Web 2.0. W specyfikacji Servlet 3.0 wprowadzono metodę startAsync () umożliwiającą asynchroniczne wykonywanie działań. Na listingu 9.3 pokazano przykład jej użycia.
Programowanie asynchroniczne w Javie EE I
Listing 9.3. Przykład użycia metody startAsync()
package com.devchronicles.asynchronous; import import import import
java.io.*; javax.servlet.*; javax.servlet.annotation.*; javax.servlet.http.*;
@WebServlet(urlPatterns={"/async"}, asyncSupported=t rue) public class AsyncServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException { final AsyncContext asyncContext = req.startAsync(); final String data; asyncContext.addListener(new AsyncListener() { @Override public void onComplete(AsyncEvent event) throws IOException { AsyncContext asyncContext = event.getAsyncContext(); asyncContext().getWriter().println(data); } @Override public void onTimeout(AsyncEvent event) throws IOException { / / kod skrócony dla zwięzłości
} @Override public void onError(AsyncEvent event) throws IOException { / / kod skrócony dla zwięzłości
} @Override public void onStartAsync(AsyncEvent event) throws IOException { / / kod skrócony dla zwięzłości
} }); new Thread() { @Override public void run() { asyncContext.complete(); } } . start () ; res.getWriter().write("Wyniki:"); / / o dczyt inform acji z b azy danych
data = "Pobrane informacje..."; / / uśpienie w ą tku na pew ien czas...
} }
141
142
I
ROZDZIAŁ 9. Asynchroniczność
Serwlet ten drukuje napis Wyniki:, a za nim informacje pobrane z bazy danych, które w tym przykładzie są zwykłym łańcuchem. Trzeba było zainicjować nowy wątek. M etoda onComplete interfejsu AsyncListener jest wywoływana po zakończeniu wykonywania. Nie jest to jedyna m etoda dotycząca cyklu życia wątku w tym interfejsie. Poniżej znajduje się opis paru innych: ^
onSta rtAsync — wykonywana po uruchom ieniu kontekstu asynchronicznego.
^
onTimeOut — wykonywana w przypadku przekroczenia limitu czasu.
^
onError — wykonywana w przypadku wystąpienia błędu.
W specyfikacji Servlet 3.1 ułatwiono implementowanie asynchronicznych serwletów przez wprowadzenie zarządzanych pól wątków i usługi wykonawczej. W przykładzie przedstawionym na listingu 9.4 do utworzenia nowego wątku użyto obiektu typu ManagedThreadFactory. Listing 9.4. Przykład użycia obiektu typu ManagedThreadFactory package com.devchronicles.asynchronous; import import import import
java.io.*; javax.servlet.*; javax.servlet.annotation.*; javax.servlet.http.*;
@WebServlet(urlPatterns="/async", asyncSupported=true) public class AsyncServlet extends HttpServlet { @Resource private ManagedThreadFactory factory; @Override protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { final AsyncContext asyncContext = req.startAsync(); final PrintWriter writer = res.getWriter(); Thread thread = factory.newThread(new Runnable() { @Override public void run() { writer. println("Skończone!"); asyncContext.complete(); } }); thread .start( ); } } W przykładzie tym utworzono nowy wątek do wykonywania czasochłonnych działań, który na koniec wywołuje funkcję complete z obiektu asyncContext. Interfejs ManagedThreadFactory służy jako dostępny wątek z puli, który należy jawnie uruchomić. Zamiast tworzyć i uruchamiać wątek w serwlecie, można wysłać asynchroniczny obiekt wykonywalny do ManagedExecutorService. Delegacja kwestii dotyczących wątków do ExecutorService pozwala otrzymać czytelniejszy kod, co widać na listingu 9.5.
Gdzie i kiedy stosować programowanie asynchroniczne
I
143
Listing 9.5. Przykład delegacji do ExecutorService
package com.devchronicles.asynchronous; import import import import
java.io.*; javax.servlet.*; javax.servlet.annotation.*; javax.servlet.http.*;
@WebServlet(urlPatterns="/async", asyncSupported=true) public class AsyncServlet extends HttpServlet { @Resource private ManagedExecutorService executor; @Override protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { final AsyncContext asyncContext = req.startAsync(); final PrintWriter writer = res.getWriter(); executor.submit(new Runnable() { @Override public void run() { writer.println("Skończone!"); asyncContext.complete(); } }); } } Choć kod ten jest tylko o jeden wiersz krótszy od poprzedniego, zadanie utworzenia i uruchomienia wątku oddelegowano w nim do ExecutorService i zajęto się tylko mechanizmem dotyczącym serwletu. Serwlety asynchroniczne są prostsze i wywierają natychmiastowy wpływ na działanie systemu wykonawczego, który przełączają bezpośrednio na model wykonywania asynchronicznego. Zapewniają też czystą implementację z niewielką ilością szablonowego kodu.
Gdzie i kiedy stosować programowanie asynchroniczne Techniki program owania asynchronicznego m ożna stosować prawie wszędzie tam, gdzie potrzebny jest wynik przed zakończeniem wykonywania całego kodu. Podejście to nie jest tożsame z asynchronicznym wykonywaniem mniej istotnych funkcji, jak obsługa dziennika czy informowanie użytkownika o postępie wykonywania czasochłonnej operacji. Asynchroniczność skraca krytyczną ścieżkę wykonawczą poprzez zlecanie niektórych zadań do wykonania innym wątkom. Efektem jest lepsza interaktywność aplikacji. M etody asynchroniczne m ożna tworzyć przy użyciu specjalnej adnotacji o nazwie ^Asynchronous, która umożliwia wykonanie kodu w osobnym wątku bez blokowania bieżącego wątku wykonawczego. Jest to doskonałe rozwiązanie w przypadkach, gdy trzeba zrobić coś, co nie m a bezpośredniego wpływu na główny cykl wykonawczy. Może to być np. rejestracja zdarzeń albo zarządzanie zasobami.
144
I
ROZDZIAŁ 9. Asynchroniczność
Asynchronicznych serwletów zapewniających asynchroniczne wykonywanie nieblokujących działań bez wykorzystania Ajaksa m ożna używać w prawie wszystkich nowoczesnych aplikacjach sieciowych. Przy ich stosowaniu program ista może zaimplementować serwerowe operacje wysyłające dane do klienta, np. aktualizacje albo powiadomienia. Do wykonania każdej asynchronicznej operacji potrzebny jest nowy wątek i w efekcie zwiększona liczba asynchronicznych m etod zmusza maszynę w irtualną Javy do częstszego przełączania kontekstów. Jeśli liczba tych kontekstów stanie się za duża, niektóre wątki ulegną zagłodzeniu, przez co wydajność program u spadnie do poziom u niższego, niż gdyby został zbudowany przy użyciu m etod synchronicznych. W yobraź sobie, że czytasz książkę. Gdy ją odkładasz, musisz zapamiętać rozwój akcji, postacie i stronę, na której skończyłeś czytanie. Jeśli czytasz dwie książki, to krótszą z nich możesz skończyć wcześniej i nie potrzebujesz do tego zakończenia tej dłuższej. Czas potrzebny na zmienianie kontekstu jednej książki na drugą nie jest zbyt długi. Ale czytanie sześciu książek jednocześnie to już całkiem inna historia. Trzeba by było tak często zmieniać kontekst, że mogłoby się nie udać ukończenie czytania żadnej z nich w oczekiwanym czasie, a zmiany mogłyby nie przynosić spodziewanego postępu. Programowanie asynchroniczne radykalnie zmienia porządek wykonywania kodu, a więc też sposób jego diagnozowania. Typową techniką diagnostyczną jest wykonywanie kodu linijka po linijce, a asynchroniczność wprowadza zamęt utrudniający zrozumienie sposobu działania program u i odtworzenie tego, co się wcześniej stało. Maszyna wirtualna Javy określa kolejność wykonywania wątków w czasie działania programu. Dokładne odtworzenie sytuacji jest prawie niemożliwe, ponieważ środowiska programistyczne i testowe znacznie różnią się między sobą pod względem dostępności zasobów. Stosowanie technik asynchroniczności bez potrzeby tylko komplikuje program. Wielowątkowość i asynchroniczność to narzędzia, którymi trzeba umieć się posługiwać, aby nie zagłodzić niektórych zasobów. Asynchroniczne wykonywanie nieblokujących części kodu jest dobrym pomysłem, ale nie należy tego robić z każdą metodą.
Podsumowanie W świecie wielordzeniowych procesorów i Web 2.0 techniki programowania asynchronicznego pozwalają efektywnie wykorzystać moce obliczeniowe komputerów, wykonywać zadania, nie blokując części program u, oraz tworzyć lepsze i bardziej interaktywne interfejsy. Nawet jeśli nie stosujesz tych technik w swojej aplikacji, są one używane w serwerach aplikacji i maszynach wirtualnych poprzez pule wątków. Wykorzystując te dostępne wątki i zasoby, możesz znacznie poprawić osiągi swoich program ów oraz polepszyć ich interaktywność. Wielowątkowe m etody program owania zajmują ważne miejsce w Javie od początku jej istnienia, ale asynchroniczne wykonywanie zadań przy użyciu wątków było zawsze problematyczne i niekoniecznie bezpieczne w kontenerach zarządzanych przez serwer. Dopiero w modelu współbieżności (Concurrency Framework) programiści Javy dostali do rąk zestaw narzędzi pozwalający im rozwinąć skrzydła. Aby Java EE nie pozostała w tyle, dodano do niej nieskom plikowany model program ow ania asynchronicznego oparty na adnotacjach. Przy użyciu adnotacji ^Asynchronous można nakazać kontenerowi asynchroniczne wykonanie funkcji.
Podsumowanie
I
145
W trzeciej wersji serwletów również wprowadzono wiele ważnych zmian, a następnie trochę kolejnych udoskonaleń w wersji 3.1. W ykorzystanie w nowym API nieblokujących operacji wejścia i wyjścia pozwoliło na stosowanie efektywnych technik asynchronicznego programowania sieciowego. Wcześniej żądanie i odpowiedź musiały być związane z wątkiem, natom iast w nowym modelu używa się wątków z wewnętrznej puli dostarczanej przez kontener. Obecnie Java EE zapewnia kom pletną bazę do asynchronicznego wykonywania kodu, eliminując potrzebę wykorzystania jakichkolwiek zewnętrznych systemów typu Spring czy Quartz. Oznacza to, że techniki program owania asynchronicznego Javy EE są doskonałym rozwiązaniem dla każdego, kto chce asynchronicznie wykonywać nieblokujący kod bez stosowania szablonowego kodu.
ĆWICZENIA 1.
Napisz implementację ziarna sesyjnego zawierającą metodę asynchroniczną.
2.
Stwórz proste rozwiązanie wykorzystujące asynchroniczne techniki programowania do zapisywania danych dziennika aplikacji w bazie danych.
3.
Przy użyciu funkcji asynchronicznych specyfikacji Servlet 3.0 zaprojektuj asynchroniczną usługę sieciową.
146
I
ROZDZIAŁ 9. Asynchroniczność
10 Usługa odmierzania czasu
ZAWARTOŚĆ ROZDZIAŁU:_______ > postęp dokonany w usłudze czasomierza; > automatyczne czasomierze; > programowe czasomierze; > ustawianie harmonogramu przy użyciu wyrażeń harmonogramowych; > czasomierze i transakcje.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r10, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. Aplikacje biznesowe wykonują zadania na podstawie kalendarza lub określonego harm onogram u, np.: generują w ten sposób tygodniowe raporty dotyczące aktywności użytkowników, zapełniają bufory albo wysyłają klientom ważne przypom nienia na adres e-mail. Usługa czasomierza pozwala zaplanować zdarzenia na określony m om ent lub w równych odstępach czasu. W tym rozdziale opisujemy sposoby konfigurowania usługi czasomierza przy użyciu technik autom atycznych i program ow ych oraz pokazujemy, jak planować wykonywanie zadań przy użyciu wyrażeń harm onogram ow ych podobnych do crona.
148
I
ROZDZIAŁ 10. Usługa odmierzania czasu
Czym jest usługa odmierzania czasu Czy potrafisz sobie wyobrazić, że codziennie rano musisz samodzielnie się obudzić, aby sprawdzić, czy już nie pora wstawania? Zanim powstały pierwsze budziki, ludzie do budzenia się stosowali różne sztuczki, np. z wykorzystaniem światła słonecznego albo kogutów. Ale słońca ani koguta nie da się konfigurować, co doprowadziło do powstania jednego z najważniejszych wynalazków nowoczesnego świata — budzika. Dziś nawet najtańszy telefon komórkowy czy asystent elektroniczny ma wbudowany budzik, który można dowolnie ustawić dla wybranych dni, a niektóre mają nawet funkcję drzemki. Jednak przez wiele lat ani w Javie SE, ani EE nie było wbudowanego mechanizm u do odmierzania czasu. Lukę tę wypełniały tworzone przez wolontariuszy otwarte rozwiązania zewnętrzne. Do wykonywania zadań na czas wykorzystywano takie narzędzia jak np. Q uartz1, ale nie były one najprostsze w obsłudze. Narzędzie takie zawsze trzeba było pobrać i zainstalować jako bibliotekę, potem należało jeszcze zaimplementować interfejsy i skonfigurować pliki XML. M ożna o nich powiedzieć wszystko, ale nie to, że nie sprawiały kłopotów. Na szczęście te trudności spowodowały, że w końcu w EJB 2.1 wprowadzono narzędzie do harmonogram owania. Dodana usługa odmierzania czasu zaspokajała najprostsze wymagania, ale do bardziej skomplikowanych zadań nadal używano biblioteki Quartz, która w końcu stała się standardowym rozwiązaniem w dziedzinie wykonywania w określonym czasie operacji w Javie. W Javie SE nie m a domyślnej implementacji czasomierzy. Biblioteki Quartz można używać zarówno w Javie SE, jak i EE, ale opis sposobów jej obsługi wykracza poza ram y tematyczne tej książki. W związku z tym pomijamy implementację w zwykłej Javie i od razu przechodzimy do Javy EE. W specyfikacji EJB 3.2 (najnowszej) usługa odmierzania czasu została znacznie udoskonalona. W prowadzono adnotacje @Schedule i @Schedules oraz wyrażenia kalendarzowe podobne do tych znanych z crona. Dzięki tym zm ianom zewnętrzne rozwiązania potrzebne są tylko w wyjątkowych przypadkach. Usługa czasomierza działa jako usługa kontenera i rejestruje ziarna EJB dla wywołań zwrotnych. Obserwuje istniejące czasomierze i ich harmonogramy i nawet zapisuje czasomierz na wypadek wyłączenia lub awarii serwera. Programiście pozostaje tylko sporządzenie harmonogramu. Usługa odm ierzania czasu przeszła wiele zmian. W tabeli 10.1 znajduje się zwięzły opis jej ewolucji. Tabela 10.1. Rozwój usługi odmierzania czasu Wersja EJB i Javy
Opis zmian
EJB 2.1 i Java 1.4 (listopad 2003)
Klasa Timer implementuje interfejs TimedObject. Dostęp do usługi TimerService uzyskuje się poprzez metodę interfejsu EJBContext. Logika biznesowa musi znajdować się w metodzie ejbTimeout.
EJB 3.0 i Java 5 (maj 2006)
Obiekt typu TimerService wstrzykuje się bezpośrednio przy użyciu adnotacji @Resource. Logika biznesowa musi znajdować się w metodzie oznaczonej adnotacją @Timeout. Harmonogram ustala się, określając datę, czas trwania, obiekt typu ScheduleExpression lub przy użyciu konfiguracyjnego pliku XML. W Javie EE 6 używa się nazwy programowalne czasomierze.
1 Q u a rtz Job Scheduler; http://w w w .quartz-scheduler.org/.
Czym jest usługa odmierzania czasu
| 149
Tabela 10.1. Rozwój usługi odmierzania czasu — ciąg dalszy Wersja EJB i Javy
Opis zmian
EJB 3.1 i Java 6 (grudzień 2009)
Kontener automatycznie dostarcza obiekt typu TimerService, co eliminuje konieczność stosowania wstrzykiwania. Logika biznesowa musi znajdować się w metodzie oznaczonej adnotacją @Schedule lub @Schedules. Harmonogram ustawia się w atrybutach adnotacji i przy użyciu wyrażeń czasowych EJB na podstawie kalendarza.
EJB 3.2 i Java 7 (czerwiec 2013)
Grupa EJB Lite została rozszerzona o nietrwałą usługę czasomierza EJB. API TimerService zostało rozszerzone o możliwość używania wszystkich aktywnych czasomierzy z modułu EJB. Ograniczenia dotyczące typów Timer i TimerHandle nakazujące, by referencje były używane tylko w ziarnach, zostało zlikwidowane.
OPOWIADANIE WOJENNE Niedawno poproszono mnie o radę w sprawie projektu internetowego, w którym występowały przejściowe problemy z wydajnością. Trudności zaczęto odnotowywać dopiero od niedawna i ich pojawienie się korelowało ze zwiększeniem liczby użytkowników witryny. W portalu wykorzystano bazę danych typu NoSQL do zapisywania danych GPS dotyczących miejsca przebywania odwiedzających. Był to właściwy wybór, ponieważ użyta baza danych zapewniała bardzo dobrą obsługę zapytań geograficznych. Regularnie wysyłano zapytania do bazy danych, która pobierała dane ze zbioru i na ich podstawie generowała raporty. Dokumenty te zawierały dane statystyczne na temat użytkowników witryny i były wytwarzane codziennie przez młodego pracownika. Szybko zauważyłem związek między czasem występowania obniżek wydajności a czasem generowania tych raportów. Wszystkiemu było winne dodatkowe obciążenie związane właśnie z tym procesem. Rozwiązanie było bardzo proste: wystarczyło sporządzać raporty w czasie, gdy baza danych była mniej obciążona. Przeanalizowałem więc raporty dotyczące poziomu obciążenia bazy danych i doszedłem do wniosku, że najlepiej czynności te jest przenieść na 3:00 w nocy. Postanowiłem zautomatyzować ten proces. W tym celu zaimplementowałem usługę odmierzania czasu do generowania raportów. Z powodów opisanych powyżej także wiele innych czynności powinno się wykonywać w godzinach nocnych. Typowym przykładem takiego zadania jest zapełnianie buforów danych skomplikowanych procesów. Powinno się to robić w czasie minimalnego obciążenia systemu.
150
I
ROZDZIAŁ 10. Usługa odmierzania czasu
Implementacja czasomierza w Javie EE W Javie EE dostępne są dwa rodzaje czasomierzy — automatyczny i programowy. Czasomierze automatyczne są ustawiane podczas wdrażania ziaren EJB zawierających metodę oznaczoną adnotacją @ Schedule(. . . ) lub @Schedules ( . . . ) . M etoda oznaczona adnotacją jest wywoływana przez planistę kontenera w określonym czasie lub co określony czas zdefiniowany w argumentach adnotacji. M etody takie nazywa się metodam i zwrotnymi. Czasomierz zaczyna odmierzanie czasu od razu po tym, jak ziarno zostanie wdrożone. Czasomierz programowy jest nastawiany w czasie działania program u przez metodę wywoływaną w kodzie logiki biznesowej. Czas m ożna ustawiać w locie, a czasomierz włączyć w dowolnej chwili (można też wcale go nie włączać). Odmierzanie czasu przez czasomierz rozpoczyna się w momencie określonym przez logikę programu.
IMPLEMENTACJA USŁUGI ODMIERZANIA CZASU Kontener EJB ma zaimplementowaną usługę odmierzania czasu. Z poziomu ziarna dostęp do tej usługi jest możliwy na trzy sposoby — przy użyciu wstrzykiwania zależności, poprzez interfejs EJBContext oraz przez wyszukiwanie w przestrzeni nazw JNDI (ang. Java Naming and Directory Interface). W tej książce opisano tylko technikę polegającą na wykorzystaniu wstrzykiwania zależności, ponieważ jest najnowsza i najbardziej efektywna.
Czasomierze automatyczne Kontener wywołuje każdą metodę oznaczoną adnotacją @Schedule zgodnie z harm onogram em zdefiniowanym w atrybutach tej adnotacji. Składnia wartości tych atrybutów jest taka sama jak składnia wyrażeń czasomierza kalendarzowego opisanych w podrozdziale „Wyrażenia czasowe”. Oto prosty przykład: @Schedule(second="*/1", minute="*", hour="*") public void executeTask(){ S ystem .out.println("Z adanie wykonane"); } W przykładzie tym m etoda executeT ask jest opatrzona adnotacją @Schedule. Dla kontenera oznacza to, że na etapie w drożenia m a nastawić czasomierz o cechach określonych w atrybutach tej adnotacji. W tym przypadku kontener będzie wywoływał metodę executeT ask co sekundę. Domyślnie wszystkie czasomierze są zapisywane i przywracane po zamknięciu lub awarii serwera. Jeśli program ista ustawi opcjonalny atrybut p e r s is t e n t na f a ls e , to po ponownym uruchom ieniu serwera czasomierz zostanie wyzerowany. Ponadto są jeszcze dwa inne atrybuty, które w razie potrzeby m ożna ustawić: in fo i tim ezone. Atrybut tim ezone służy do określania strefy czasowej, w odniesieniu do której m a działać czasomierz. Jeśli się go nie zdefiniuje, stosowana jest strefa czasowa serwera. Natomiast atrybut in fo służy do dodawania opisu, który można pobrać za pomocą metody g e tIn fo interfejsu Timer. @Schedule(hour = "23", minute = "59", timezone = "CET", info = "Generuje raport co noc.") public void executeTask(){ S ystem .out.println("Z adanie wykonane"); }
Implementacja czasomierza w Javie EE I
151
Zdefiniowana w tym przykładzie m etoda executeT ask będzie wywoływana o 23:59 czasu środkowoeuropejskiego niezależnie od tego, w jakiej strefie czasowej znajduje się serwer, na którym ta m etoda będzie wykonywana. Metoda g e tIn fo zwróci napis G eneruje ra p o rt co noc. Przy użyciu adnotacji @Schedules m ożna definiować bardziej skomplikowane czasomierze (zwróć uwagę na literę 5 na końcu nazwy) zawierające więcej niż jedno wyrażenie czasowe. @Schedules({ @Schedule(dayOfMonth = "1"), @Schedule(dayOfWeek = "Mon,Tue,Wed,Thu,Fri", hour = "8") }) public void executeTask() { S ystem .out.println("Z adanie wykonane"); } Ten czasomierz włącza się pierwszego dnia każdego miesiąca i w każdym dniu roboczym o 8:00. Na listingu 10.1 przedstawiono kom pletny przykład automatycznego czasomierza. Listing 10.1. Najprostsza implementacja automatycznego czasomierza package com .devchronicles.tim er; import javax.ejb.S chedule; import javax.ejb.S chedules; public c la ss PeriodicTimer { @Schedules({ @Schedule(dayOfMonth = "1"), @Schedule(dayOfWeek = "Mon,Tue,Wed,Thu,Fri", hour = "8") }) public void executeTask() { S ystem .out.println("Z adanie wykonane"); } } Jedną z wad automatycznego czasomierza jest to, że jego harm onogram ustawia się w fazie wdrożeniowej i nie m ożna go zmienić podczas działania aplikacji. W razie potrzeby można wykorzystać czasomierz program owy ustawiany w czasie wykonywania programu.
Czasomierze programowe Czasomierze programowe tworzy się w czasie wykonywania program u za pomocą wywołania jednej z przeznaczonych do tego celu m etod interfejsu T im erService. Oto prosty przykład: public void setTim er(){ tim erService.createTim er(30000, "Nowy czasomierz"); } M etoda setT im er utworzy jednorazowy czasomierz, który po upływie 30 000 milisekund wywoła metodę „limitu czasu” z tego samego ziarna. Metodę „limitu czasu” oznacza się adnotacją @Timeout i musi ona spełniać pewne wymagania. Nie może np. zgłaszać wyjątków ani zwracać wartości. Nie musi też pobierać parametru, a jeśli to robi, to musi on być typu ja v a x . ejb .Time. Może istnieć tylko jedna taka metoda.
152
| ROZDZIAŁ 10. Usługa odmierzania czasu
@Timeout public void performTask() { System.out.println("W ykonano p roste zadanie"); } Kontener CDI wstrzykuje referencję do obiektu typu Tim erService zmiennej egzemplarzowej opatrzonej adnotacją @Resou rce. W poniższym przykładzie wstrzykiwana jest zmienna egzemplarzowa tim e rS e rv ic e . @Resource TimerService tim erService; Jeśli trzy powyższe przykłady zbierze się w jedno ziarno i w aplikacji wywoła się metodę setT imer, to powstanie czasomierz, który po 30 sekundach wywoła metodę „limitu czasu” o nazwie performTask. Na listingu 10.2 przedstawiono najprostszą możliwą implementację czasomierza programowego w Javie EE 7. Listing 10.2. Najprostsza implementacja czasomierza programowego package com .devchronicles.tim er; import javax.annotation.R esource; import javax.ejb.Tim eout; import javax.ejb.T im erService; public c la ss SimpleProgrammaticTimer { @Resource TimerService tim erService; public void setTim er(){ tim erService.createTim er(30000, "Nowy czasomierz"); } @Timeout public void performTask() { System.out.println("W ykonano p ro ste zadanie"); } } W interfejsie T im erService znajdują się cztery m etody do tworzenia czasomierzy, które w sumie mają dziesięć sygnatur. W tabeli 10.2 przedstawiono po przykładzie użycia każdej z nich. Tabela 10.2. Przykłady użycia metod do tworzenia czasomierzy z interfejsu TimerService Metoda
Opis
createIntervalTimer(new Date(), 10000, new TimerConfig());
Tworzy czasomierz uruchamiany określonego dnia, a następnie co 10 sekund.
createSingleActionTimer(1000, new TimerConfig());
Tworzy czasomierz uruchamiany co 1 sekundę.
createTimer(30000, "Utworzono nowy czasomierz programowy");
Tworzy czasomierz uruchamiany po upływie 30 sekund.
createCalendarTimer(new ScheduleExpression().second("*/10"). minute("*").hour("*"));
Tworzy czasomierz uruchamiany co 10 sekund.
Implementacja czasomierza w Javie EE I
153
Wszystkie te m etody oprócz createC alen d arT im er jako pierwszy param etr przyjmują liczbę milisekund lub datę określającą czas uruchom ienia czasomierza. Oto przykład: SimpleDateFormat form atter = new SimpleDateFormat("dd/MM/yyyy 'a t ' HH:mm"); Date date = form atter.parse("26/01/2016 at 17:56"); tim erS ervice.createS ingleA ctionT im er(date, new TimerConfig()); W tym przykładzie metoda „limitu czasu” zostanie uruchom iona o 17:56 26 stycznia 2016 r. Jeśli potrzebny jest czasomierz z harm onogram em , m ożna użyć metody createC alendarT im er. Jako argum ent przyjmuje ona obiekt typu S chedu leE xpression zawierający ustawienia harm onogram u wykonane zgodnie z zasadami opisanymi w podrozdziale „W yrażenia czasowe”. ScheduleExpression expression = new ScheduleExpression(); expression.seco n d ("* /1 0 ").m in u te("* ").h o u r("* "); tim erS ervice.createC alendarT im er(expression); W tym przykładzie harm onogram jest urucham iany co dziesięć sekund każdej m inuty każdej godziny. Wszystkie opisywane m etody zwracają obiekt typu Time r reprezentujący czasomierz. Zawiera on metodę getH andle, która zwraca serializowalny uchwyt do czasomierza. Uchwyt ten w razie potrzeby można zapisać w bazie danych lub pamięci. Później zapisany obiekt uchwytu m ożna odzyskać i zwrócić referencję do czasomierza za pomocą m etody getTim er. Przy użyciu tego obiektu m ożna zdobyć cenne informacje o czasomierzu. Informacje o sposobie działania czasomierza są łatwo dostępne. H arm onogram m ożna sprawdzić przy użyciu metody getS chedule. Zwraca ona obiekt typu ScheduleE xpression zawierający metodę pobierającą wartość dla każdego atrybutu. Na przykład m etoda getM inute () zwraca wartość atrybutu określającego liczbę m inut, metoda getNextTimeout miejsce następnego uruchom ienia czasomierza, a m etoda getTimeRemaining liczbę milisekund pozostałą do wygaśnięcia czasomierza. M etoda isC alen d arT im er zwraca wartość tr u e , jeśli czasomierz został nastaw iony przez utworzenie obiektu typu S cheduleE xpression. Należy ją wywołać przed m etodą getS chedule, aby dowiedzieć się, jak został utw orzony czasomierz. W przeciwnym razie m etoda ta zgłosi wyjątek Ille g a lS ta te E x c e p tio n . Informacje o trwałości czasomierza można zdobyć za pomocą m etody is P e r s is te n t. W analogiczny sposób m ożna też uzyskać informacje o czasie za pomocą metody g e tIn fo . Czasomierze po wygaśnięciu są automatycznie anulowane. Kontener anuluje czasomierze jednorazowe, natom iast program ista może likwidować czasomierze zaplanowane za pomocą wywołania m etody can cel na obiekcie typu Timer.
Wyrażenia czasowe Zarówno w programowych, jak i automatycznych czasomierzach do określania czasu można używać atrybutów kalendarzowych. W tabeli 10.3 znajduje się ich lista. Dla czasomierzy automatycznych atrybuty ustawia się w adnotacji, natom iast dla czasomierzy programowych robi się to przy użyciu m etod klasy ScheduleE xpression.
154
| ROZDZIAŁ 10. Usługa odmierzania czasu
Tabela 10.3. Wyrażenia kalendarzowe Atrybut
Opis
Zakres wartości
second
Jedna lub więcej sekund w czasie minuty
Od 0 do 59
minute
Jedna lub więcej minut w czasie godziny
Od 0 do 59
hour
Jedna lub więcej godzin w czasie dnia
Od 0 do 23
dayOfWeek
Jeden lub więcej dni w czasie tygodnia
Od 0 do 7 (0 i 7 oznaczają niedzielę) Od Sun do Sat
dayOfMonth
Jeden lub więcej dni w czasie miesiąca
Od 1 do 31 Od -7 do - 1 (dni od końca miesiąca) Last 1st, 2nd, 3rd, 4th itd. Od Sun do Sat
month
Jeden lub więcej miesięcy w czasie roku
Od 1 do
12
Od Jan do Dec year
Konkretny rok kalendarzowy
2014, 2015 itd.
Domyślna wartość wszystkich atrybutów czasowych to 0 (zero), a w przypadku wartości nienum erycznych jest to * (gwiazdka). Tabelę tę skopiowaliśmy z kursu program owania w Javie EE 7 firmy Oracle2. Składnia tych wyrażeń jest podobna do składni crona, więc większość programistów powinna ją znać. Jest również parę ważnych cech, o których należy wiedzieć. Gwiazdka jest symbolem zastępczym dla wszystkich możliwych wartości danego atrybutu. Aby np. zaplanować wykonywanie czegoś co godzinę, w czasomierzu nastawianym przy użyciu adnotacji można by było zdefiniować wyrażenie hour="*". Natomiast w przypadku czasomierza programowego należałoby wywołać m etodę h o u r("* ") na egzemplarzu klasy ScheduleExpression. W artościami atrybutów mogą też być listy i przedziały. Na przykład wyrażenie dayOfMonth="1, 15, l a s t " ustawia czasomierz na pierwszy, piętnasty i ostatni dzień każdego miesiąca, a wyrażenie hour="8-18" reprezentuje każdą godzinę w czasie od 8:00 do 18:00. W razie potrzeby można też definiować odstępy czasowe z m om entem rozpoczęcia. Na przykład wyrażenie hour="*/12" oznacza wykonanie czynności co dwanaście godzin. Cykle takie można definiować tylko w sekundach, m inutach i godzinach. W tabeli 10.4 przedstawiono kilka praktycznych przykładów zastosowania wyrażeń czasowych. W EJB 3.2 dodano do interfejsu API usługi czasowej możliwość dostępu do wszystkich czasomierzy aktywnych w module EJB. Dotyczy to zarówno czasomierzy programowych, jak i automatycznych. Na listingu 10.3 przedstawiono przykład użycia tych nowych funkcji.
2 K urs p ro g ram o w a n ia w Javie EE 7 firm y O racle; https://docs.orade.m m /javaee/7/tutorial/ejb-basicexam ples004.htm #G IQ LY .
Implementacja czasomierza w Javie EE | 155
Tabela 10.4. Praktyczne przykłady wyrażeń Wyrażenie
Opis
Second="10"
Co 10 sekund
hour = "2",
Co 2 godziny
minute = "15"
Co 15 minut
dayOfWeek="Mon, Fri"
W każdy poniedziałek i piątek o północy
dayOfWeek="0-7", hour="8"
Codziennie o 8:00
dayOfMonth="-7"
Siedem dni o północy przed końcem każdego miesiąca
dayOfMonth="1st Mon", hour="22"
Pierwszy poniedziałek każdego miesiąca o 22:00
Month="Mar", dayOfMonth="15"
Piętnasty dzień najbliższego marca
year="2015", month="May"
1 maja 2015 r. o północy
Listing 10.3. Każdy czasomierz można pobrać i zmodyfikować package com .devchronicles.tim er; import import import import import import import
ja v a .u til.C o lle c tio n ; javax.annotation.P ostC onst r u c t; javax.annotation.R esource; jav a x .e jb .S in g le to n ; ja v a x .e jb .S ta rtu p ; javax.ejb.T im er; javax.ejb.T im erService;
@Singleton @Startup public c la ss AllTimers { @Resource TimerService tim erService; @PostConst ruct public void manageTimer(){ Collection tim ers = tim erS ervice.getA llT im ers(); for(Timer t : tim ers){ S ystem .o u t.p rin tln ("In fo rm acje o czasomierzu: " + t.g e tI n f o ( ) ) ; S y stem .o u t.p rin tln ("P o zo stały czas: " + t.getTim eRem aining()); t . c a n c e l(); } } } N a początku tego przykładu tworzone jest ziarno i zostaje wywołana metoda manageTimer. Pobieramy zbiór wszystkich aktywnych czasomierzy, za pomocą pętli przeglądamy jego elementy i dla każdego z nich drukujem y informacje oraz liczbę milisekund pozostałych do następnego zaplanowanego wygaśnięcia. Na koniec anulujem y czasomierz.
156
I
ROZDZIAŁ 10. Usługa odmierzania czasu
Transakcje Ziarna tworzą czasomierze w transakcjach zarządzanych przez kontener. Jeżeli transakcja zostanie cofnięta, to samo dzieje się z czasomierzem, tzn. jeśli czasomierz został anulowany, to anulowanie to będzie cofnięte i nastąpi ponowne nastawienie czasomierza. Na listingu 10.4 przedstawiamy przykład metody czasowej oznaczonej adnotacją transakcyjną. Listing 10.4. Czasomierz może ustawiać atrybut transakcji package com .devchronicles.tim er; import javax.annotation.R esource; import javax.ejb.Tim eout; import javax.ejb.T im erService; public c la ss SimpleProgramaticTimer { @Resource TimerService tim erService; public void setTim er(){ ScheduleExpression expression = new ScheduleExpression(); expression .seco n d ("* /1 0 ").m in u te("* ").h our("*"); tim er = tim erService.createC alendarTim er( new ScheduleE xpression().second("*/10").m inute("*").hour("*")); } @Timeout @TransactionAttribute(TransactionAttributeType.REQUIRED) public void performTask() { System.out.println("W ykonano p roste zadanie"); } } W ziarnach wykorzystujących transakcje zarządzane przez kontener atrybut transakcji ustawia się dla metody oznaczonej adnotacją @Timeout. W artością tego atrybutu jest wartość wyliczenia T ra n sa c tio n A ttrib u te T y p e — Required lub RequiresNew. Uruchomienie transakcji następuje przed wywołaniem metody. W przypadku wycofania transakcji m etoda @Timeout zostanie wywołana jeszcze raz.
Podsumowanie W tym rozdziale opisaliśmy m etody tworzenia automatycznych i programowych czasomierzy oraz sposób ich działania w transakcjach. Czasomierzy używa się podobnie jak crona do wykonywania zadań w określonym czasie lub co określony czas bez naruszania głównej logiki biznesowej. Narzędzia te m ożna znaleźć w wielu projektach i prawie wszystkich językach programowania. Czasomierz autom atyczny tworzy się przez dodanie do m etody adnotacji @Schedule lub @Schedules i zdefiniowanie jego wartości jako atrybutów adnotacji w deskryptorze wdrożenia ejb-jar.xml. Czasomierze programowe są tworzone przez kod aplikacji i m ożna zmieniać ich wartości w czasie działania programu.
Podsumowanie
| 157
W ybór typu czasomierza zależy głównie od tego, czy częstotliwość wykonywania zdarzeń może się zm ieniać zależnie od logiki biznesowej (usługi klienckie), czy z powodów technicznych (napełnianie bufora). W drugim z wymienionych przypadków lepiej jest użyć czasomierza program owego, natom iast w pierwszym korzystniejszy będzie czasomierz automatyczny. Czasomierze są domyślnie zapisywane na wypadek awarii serwera, można je też serializować w celu zapisania w bazie danych i użycia w późniejszym czasie. Ponadto czasomierze podlegają standardowym zasadom działania transakcji, tzn. w razie problemów z wykonaniem jej w całości są wraz z nią wycofywane. W EJB 3.2 wprowadzono udoskonalenia ułatwiające pracę z czasomierzami. Umożliwiono pobieranie wszystkich aktywnych czasomierzy i wywoływanie na każdym egzemplarzu metod. Dzięki postępowi w rozwoju języka Java czasomierze w Javie EE stały się solidnym i przydatnym rozwiązaniem, przez co większość implementujących je zewnętrznych systemów straciła rację bytu.
ĆWICZENIA 1.
Napisz bufor wstawiający do słownika dane z bazy danych. Nastaw na 3:00 w nocy usługę czasową wywołującą metodę zapełniającą ten bufor.
2.
Napisz czasomierz programowy wysyłający do klienta powiadomienie, gdy trzeba odnowić subskrypcję.
158 | ROZDZIAŁ 10. Usługa odmierzania czasu
11 Wzorzec Obserwator
ZAWARTOŚĆ ROZDZIAŁU:_______ > implementacja wzorca Obserwator w zwykłym kodzie; > zastosowanie wzorca Obserwator w realnych programach; > implementacja wzorca Obserwator przy użyciu adnotacji @Observes i zdarzeń; > precyzyjne kontrolowanie obserwatorów przy użyciu kwalifikatorów; > stosowanie obserwatorów z transakcjami i wycofywanie ich zmian.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r11, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. O bserw ato r to jeden z najpowszechniej znanych i stosowanych wzorców projektowych w nowoczesnych językach programowania, program ach i systemach szkieletowych do budowy interfejsów użytkownika. W większości języków program owania wzorzec ten jest wykorzystywany w wewnętrznych interfejsach API i Java nie należy tu do wyjątków. Twórcy Javy EE posunęli się nawet o krok dalej i dostarczyli domyślną implementację Obserwatora, dzięki czemu programista nie musi go samodzielnie implementować od zera. Głównym tematem tego rozdziału jest właśnie domyślna implementacja wzorca projektowego Obserwator w Javie. Dowiesz się, kiedy jej używać, jak definiować obserw atory za pom ocą adnotacji oraz jak posługiwać się obserwatoram i w transakcjach.
160
I
ROZDZIAŁ 11. Wzorzec Obserwator
Czym jest Obserwator Istotą wzorca projektowego Obserwator jest to, że jeśli pewien obiekt zmieni swój stan, to informuje o zaistniałym zdarzeniu inne obiekty. W nomenklaturze wzorców projektowych obiekt zmieniający stan nazywa się p o dm iotem (ang. subject), a obiekty otrzymujące powiadomienia o zmianach — obserw atoram i (ang. observer). Jest to relacja typu jeden do wielu, tzn. jeden podm iot może być obserwowany przez wiele obserwatorów. Wyobraź sobie komunikator internetowy, który co sekundę automatycznie odświeża zawartość okna, aby wyświetlić ewentualne nowe wiadomości. Program ten ma też funkcję pozwalającą na rozmowę wielu osób jednocześnie. Każdy uczestnik komunikacji regularnie sprawdza, czy na serwerze pojawiły się nowe wiadomości wysłane przez kogoś z pozostałych użytkowników. Nietrudno sobie wyobrazić, jak bardzo nieefektywne jest to rozwiązanie. Czy nie lepiej, gdyby nowe wiadomości były same wysyłane do klientów? Na pewno byłoby to o wiele bardziej efektywne. Takie rozwiązanie reprezentuje właśnie wzorzec projektowy Obserwator. Obserwatorem w tym przypadku byłby serwer czatu, a klienci byliby podmiotam i. Serwer byłby zarejestrowany u każdego klienta i gdyby któryś z nich wysłał nową wiadomość (zmiana stanu podm iotu), podm iot wywoływałby metodę na serwerze w celu powiadomienia go o nowej wiadomości. Później serwer wywoływałby metodę na wszystkich swoich klientach i do każdego z nich wysyłałby wiadomość. UWAGA Wzorzec Obserwator nazywany jest też zasadą Hollywood (ang. Hollywood principie), ponieważ motto fabryki snów mówi: „Nie dzwoń do nas, my zadzwonimy do ciebie". Chodzi oczywiście o to, że większość agentów woli sama dzwonić do wybranych aktorów z propozycjami ról zamiast ciągle odpowiadać na telefony z pytaniami, czy nie mają do zaoferowania jakiejś. System ten działa doskonale, ponieważ nigdy nie jest odpowiedni czas na to, by zadzwonić do agenta z pytaniem o pracę. Gdyby oferty pojawiały się częściej niż dzwonimy, to niektóre z nich na pewno byśmy przeoczyli. A gdybyśmy dzwonili częściej niż pojawiają się oferty, to zostalibyśmy uznani za natrętów. Postępując zgodnie z wzorcem Obserwator, agent dzwoni do odpowiednich klientów tylko wtedy, gdy ma dla nich ofertę, i nie traci czasu na jałowe rozmowy.
Opis W książce Bandy Czworga1 znajdujemy następujący opis wzorca projektowego Obserwator: „definiuje między obiektami zależność typu jeden do wielu, która polega na tym, że gdy zmieni się stan jednego obiektu, pozostałe są automatycznie o tym powiadamiane i odpowiednio aktualizowane”. Natom iast w książce Wzorce projektowe. R usz głową!2 przedstawiono przykład aplikacji do m onitorow ania pogody, która wysyła powiadom ienie, gdy zmieni się tem peratura. Wzorzec Obserw ator jest oparty na zasadach dziedziczenia i należy do wzorców behawioralnych. Aby stać się obserwatorem, wszystkie konkretne implementacje muszą współdzielić podobny interfejs. Każdy obserwator może dodać podm iot do swojego rejestru. Gdy w podmiocie coś się zmieni, obserwator zostaje o tym powiadomiony. 1 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010. 2 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010.
Czym jest Obserwator
| 161
Jest to efektywne rozwiązanie, ponieważ zm iana powoduje tylko jedno wywołanie u każdego obserwatora. Prymitywne rozwiązanie polegające na sprawdzaniu zmian w regularnych odstępach czasu może wymagać wykonania nieskończonej liczby wywołań u różnych obserwatorów, nawet jeśli nie wystąpi ani jedna zm iana w obserwowanym obiekcie. W zorzec projektowy Obserwator m ożna porównać z subskrypcją najświeższych wiadomości. Obiekty chcące zasubskrybować informacje o zm ianach w innym obiekcie rejestrują się, aby otrzymywać odpowiednie powiadomienia. Obiekty, zamiast sprawdzać obiekt docelowy, są wywoływane, gdy nastąpi jakaś zmiana. Inną typową dziedziną, w której powszechnie wykorzystuje się wzorzec Obserwator, są systemy szkieletowe do budowy interfejsów użytkownika, chociaż dotyczy to bardziej aplikacji na komputery osobiste niż programów biznesowych. W kontekście tych systemów wzorzec Obserwator często jest nazywany wzorcem o d biornika (ang. listener), ale zasadniczo jest to to samo. Zgodnie z zasadami tego wzorca zbudowane są np. procedury nasłuchujące zdarzeń kliknięcia przycisku, obsługujące operację przeciągania i upuszczania elementów oraz zmieniające wartości. Prawie wszystkie sieciowe systemy szkieletowe są zbudowane na podstawie wzorca projektowego Model - W idok - Kontroler, który wewnętrznie również wykorzystuje obserwatory. Więcej informacji na ten tem at znajduje się w rozdziale 14., „Wzorzec Model - W idok - Kontroler”.
OPOWIADANIE WOJENNE Kiedyś jednym z moich obowiązków w pracy było doradzanie stażystom i absolwentom. W tym opowiadaniu wspominam utalentowaną stażystkę, z którą miałem okazję jakiś czas pracować. Była to bystra absolwentka studiów elektronicznych, która lepiej znała się na sprzęcie i programowaniu strukturalnym niż na obiektowych językach programowania. Miała więc niewielkie pojęcie o wzorcach projektowych, ale właśnie ukończyła z powodzeniem projekt Arduino3. Zaczęliśmy pracę nad aplikacją na Androida wykorzystującą systemową funkcję wykrywania twarzy do sprawdzania, czy w danej chwili na ekran patrzy użytkownik. Mając jeszcze świeżo w pamięci poprzedni projekt Arduino, stażystka wpadła na pomysł, aby napisać pętlę do sprawdzania, czy kamera wykryła nową twarz. Pętla ta miała działać w głównym wątku aplikacji, więc blokowała cały program. Gdy zorientowała się, że został zablokowany wątek obsługujący interfejs użytkownika, stażystka postanowiła przenieść algorytm wykrywania twarzy do osobnego wątku. Krótko mówiąc: zastosowała podejście typu: „Jeśli dysponujesz tylko młotkiem, to każdy problem wydaje ci się gwoździem"4. Porozmawialiśmy trochę na temat struktury aplikacji Arduino. W tej technologii cały program jest pętlą, która działa, dopóki programista sam jej nie zatrzyma. Zawiera ona całą funkcjonalność programu. Ale nasza aplikacja na Androida była inna. Zamiast ciągle wysyłać do kamery zapytania, czy przypadkiem nie pojawiła się jakaś twarz, program ten powinien czekać na informację. Gdy stażystka zrozumiała istotę wzorca Obserwator, to jego implementacja nie sprawiła jej już żadnego problemu, ponieważ budowa systemu Android jest oparta na tym wzorcu. Wystarczyło więc tylko dodać odpowiednią klasę nasłuchową i wywołać wybraną funkcję po wykryciu twarzy.
3 N iew ielka p łytka do b u d o w a n ia układ ó w elektronicznych; http://w w w .arduino.cc. 4 A b rah am M aslow (1908 - 1970) — am erykański psycholog.
162
I
ROZDZIAŁ 11. Wzorzec Obserwator
Diagram klas wzorca Obserwator Jak widać na rysunku 11.1, wzorzec Obserwator wprowadza interfejs Observer, który musi być zaimplementowany przez wszystkie konkretne obserwatory. Interfejs ten m a tylko jedną metodę wywoływaną przez podm iot w celu powiadomienia obserwatorów, że nastąpiła zmiana stanu. Każdy podm iot przechowuje listę zarejestrowanych obserwatorów i wywołuje metodę notifyObservers w celu poinform ow ania ich o zm ianach swojego stanu. Podm iot zawiera m etody służące do rejestrowania i wyrejestrowywania obserwatorów.
Rysunek 11.1. Diagram klas wzorca projektowego Obserwator
Implementacja wzorca Obserwator w zwykłym kodzie Języka Java zapewnia gotową implementację wzorca projektowego Obserwator. Programista ze swojej strony musi tylko zaimplementować interfejs Observer i rozszerzyć klasę Observable. Pierwszą czynnością powinno być utworzenie klasy rozszerzającej klasę Observable. Na listingu 11.1 przedstaw iono przykład agencji informacyjnej powiadamiającej kilka typów subskrybentów o pojawiających się nowych wiadomościach. Subskrybent po otrzym aniu aktualizacji może wykonać własne funkcje. N atom iast na listingu 11.2 przedstaw iono interfejs do publikowania klasy, którą m ożna obserwować. Listing 11.1. Agencja informacyjna implementująca obserwowalny interfejs package com.devchronicles.observer; import import import import
java.util.ArrayList; j ava. ut il. Lis t; java.util.Observable; java.util.Observer;
public class NewsAgency extends Observable implements Publisher { private List channels = new ArrayList<>();
Implementacja wzorca Obserwator w zwykłym kodzie
| 163
public void addNews(String newsItem) { notifyObservers(newsItem ); } public void notifyO bservers(S tring newsItem) { fo r (Observer o u tle t : th is.c h a n n e ls) { o u tle t.u p d a te ( th is , newsItem); } } public void register(O b serv er o u tle t) { c h a n n e ls.a d d (o u tle t); } } Listing 11.2. Interfejs Publisher package com .devchronicles.observer; public in te rfa c e P ublisher {} Następnym krokiem jest napisanie klasy obserwującej zmiany w obiekcie klasy NewsAgency. Obserwator ten musi implementować interfejs O bserver — listing 11.3. Listing 11.3. Konkretny obserwator package com .devchronicles.observer; import ja v a .u til.O b se rv a b le; import ja v a .u til.O b se rv e r; public c la ss RadioChannel implements Observer { @Override public void update(Observable agency, Object newsItem) { i f (agency instanceof Publisher) { S y ste m .o u t.p rin tln ((S t ring)newsItem); } } } N a koniec zarejestrujemy obserwator RadioChannel w obserwowalnym obiekcie NewsAgency i utworzymy kilka wiadomości. / / utw orzenie obserwatora i p o d m io tu
NewsAgency newsAgency = new NewsAgency(); RadioChannel radioChannel = new RadioChannel(); / / rejestracja obserwatora w podm iocie
newsAgency.register(radioChannel) ; / / kilka nagłów ków
newsAgency.addNews("Pilna wiadomość: Znaleziono życie na M arsie"); newsAgency.addNews("Aktualizacja: Zbliża się zagłada Ziemi"); newsAgency.addNews("Z o s ta tn ie j chw ili: W itajcie naszych m arsjańskich władców");
164
I
ROZDZIAŁ 11. Wzorzec Obserwator
W konsoli powinny pojawić się następujące wyniki: Pilna wiadomość: Znaleziono życie na Marsie A ktualizacja: Zbliża się zagłada Ziemi Z o s ta tn ie j chw ili: W itajcie naszych m arsjańskich władców Podkreślmy, że w obiekcie NewsAgency m ożna zarejestrować wiele obserwatorów do odbierania wiadomości. Oprócz już zarejestrowanego m ożna by było np. dodać obserwatory TVChannel i I n te rnetNewsChannel. Ponadto w razie potrzeby m ożna też utworzyć innych wydawców (albo jakikolwiek inny typ obiektu implementujący interfejs Obse rvable) wysyłających aktualizacje do zarejestrowanych obserwatorów. Obserwatory te mogłyby sprawdzać typ obiektu obserwowalnego i przetwarzać otrzym aną wiadomość zależnie od źródła jej pochodzenia. Jedną z poważnych wad takiej implementacji wzorca Obserwator jest konieczność rozszerzania klasy O bservable. W ym usza to używanie hierarchii klas, co nie zawsze jest pożądane przez program istę. W Javie jedna klasa może bezpośrednio rozszerzać tylko jedną inną klasę, więc technika ta ogranicza pole manewru w zakresie projektowania hierarchii. Brak możliwości dodania funkcjonalności klasy O bservable do istniejącej klasy, która rozszerza już jakąś inną klasę, znacznie zawęża potencjalny wachlarz zastosowań. N a szczęście nie jest całkiem źle, ponieważ wzorzec Obserwator m ożna też zaimplementować „ręcznie” bez używania interfejsu Observer i klasy O bservable. Wystarczy skorzystać z pokazanego wcześniej diagramu klas, ale ponieważ tem atem tej książki jest Java EE, implementację tę pozostawiamy jako ćwiczenie do samodzielnego wykonania.
Implementacja wzorca Obserwator w Javie EE Choć Java obsługuje wzorzec Obserwator od samego początku, jego implementacja w Javie EE jest znacznie łatwiejsza dzięki adnotacji @Observes i interfejsowi ja v a x .e n te r p ris e .e v e n t .Event. Każda m etoda opatrzona adnotacją @Observes nasłuchuje zdarzeń pewnego typu. Gdy „usłyszy” takie zdarzenie, param etr m etody obserwatora otrzymuje egzemplarz tego typu i następuje wykonanie tej metody. Przy użyciu adnotacji @Observes m ożna sprawić, aby dowolna m etoda nasłuchiwała zdarzeń i była wywoływana z określonym typem obiektu. Na listingu 11.4 znajduje się jedno ziarno wyzwalające zdarzenie typu S trin g i drugie ziarno nasłuchujące zdarzeń tego typu od pierwszego ziarna. Listing 11.4. Obserwowalne ziarno usługowe package com .devchronicles.observer; import import import import import
ja v a x .e jb .S ta te le s s ; jav ax .e jb .T ra n sa c tio n A ttrib u te; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .e n te rp rise.e v e n t.E v e n t; ja v a x .in je c t.I n je c t;
@ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss EventService { @Inject
Implementacja wzorca Obserwator w Javie EE | 165
p riv a te S tring message; @Inject Event event; public void s ta rtS e rv ic e (){ event.fire("U rucham ianie u sługi " + message); } } Kontener wstrzykuje obiekt zdarzeniowy typu S trin g do zmiennej egzemplarzowej event klasy EventS ervice. Stanowi ona część wiadomości, gdy zostanie wyzwolony obiekt zdarzenia. Zmienna egzemplarzowa reprezentująca wiadomość jest łańcuchem, który m ożna utworzyć przy użyciu fabryki. (Więcej informacji na tem at wzorca projektowego Fabryka znajduje się w rozdziale 6., „Wzorzec Fabryka”). Aby przykład ten zadziałał bez tworzenia fabryki, można zdefiniować stałą łańcuchową w zmiennej o nazwie message i usunąć adnotację @ Inject: p riv a te S tring message = "wiadomość"; Część obserwowalna jest gotowa, więc możemy utworzyć obserwator, który będzie nasłuchiwał naszych zdarzeń typu S trin g . Dodatek adnotacji @Observes do sygnatury metody oznacza tę metodę jako obserwatora zdarzeń typu podanego dalej. W tym przypadku adnotacja @Observes poprzedza nazwę typu S trin g , więc nasłuchuje zdarzeń łańcuchowych. Gdyby znajdowała się po niej nazwa typu obiektowego, to oznaczona m etoda obserwowałaby zdarzenia tego typu. Na listingu 11.5 zastosowano adnotację @Observes w sygnaturze m etody se rv ic eT rac e, która wyznacza tę metodę jako obserwatora zdarzeń typu St ring. Gdy wystąpi zdarzenie typu St ring, m etoda se rv ic e T rac e otrzyma obiekt tego zdarzenia poprzez swój param etr i będzie mogła go przetworzyć w dowolny sposób. W tym przypadku drukujemy wiadomość w konsoli. Listing 11.5. Ziarno obserwatora package com .devchronicles.observer; import ja v a x .e jb .S ta te le s s ; import jav ax .en terp rise.ev en t.O b serv es; @ Stateless public c la ss TraceObserver { public void serviceTrace(@Observes S tring message){ System.out.println("W iadomość z usługi: " + message); } } Jeśli włączysz serwer i wywołasz metodę s ta r tS e r v ic e , to zauważysz, że do klasy E ventService zostanie magicznie wstrzyknięty łańcuch, a następnie zostanie wyzwolone zdarzenie łańcuchowe, które „zaobserwuje” m etoda se rv ic e T rac e klasy T raceO bserver, po czym nastąpi wydrukowanie wiadomości w konsoli. Co ciekawe, jest to cała implementacja wzorca Obserwator w Javie EE. Nie trzeba nic więcej ustawiać. Choć w prawdziwych program ach raczej nie zgłasza i nie przechwytuje się zdarzeń będących zwykłymi łańcuchami, lecz własne typy obiektów, rozróżnienie typów obiektowych i utworzenie dla nich obserwatorów też nie sprawiłoby nikom u problemu.
166
I
ROZDZIAŁ 11. Wzorzec Obserwator
Poniżej przedstawiamy przykład użycia kwalifikatorów do rozróżnienia obiektów typu St ring. O efektywności tej techniki przekonałeś się już przy implementacji wzorca Fabryka tworzącej różne implementacje tego samego typu obiektów. Na listingu 11.6 znajduje się kod rozróżniający łańcuchy. Listing 11.6. Interfejs kwalifikacyjny adnotacji package com .devchronicles.observer; import import import import import
java.lang.annotation.Elem entT ype; jav a.lan g .an n o tatio n .R eten tio n ; jav a.lan g .an n o tatio n .R eten tio n P o licy ; ja v a .la n g .a n n o ta tio n .T a rg e t; ja v a x .in je c t.Q u a lifie r;
@Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD,ElementType.PARAMETER}) public @ interface MessageEvent { Type v a lu e (); enum Type{ SERVICE, PARAMETER } Jest to definicja kwalifikatora MessageEvent i dwóch typów wyliczeniowych (SERVICE i PARAMETER), których będziemy używać w charakterze adnotacji do oznaczania łańcuchów do wyzwalania jako egzemplarzy zdarzeń. import com.devchronicles.observer.M essageEvent.Type; @ Stateless @ T ransactionA ttribute(T ransactionA ttributeT ype.REQUIRED) public c la ss EventService { @Inject p riv a te S tring message; @Inject @MessageEvent(Type.SERVICE) Event serviceEvent; @Inject @MessageEvent(Type.PARAMETER) Event parameterEvent; public void s ta rtS e rv ic e (){ serviceE vent.fire("U rucham ianie u sługi "+message); p aram eterE v en t.fire("-d -p "); } Aby użyć kwalifikatorów, należy dodać adnotację MessageEvent do odpowiedniego wstrzykniętego egzemplarza z żądanym typem wyliczenia w nawiasie. Następnie wyzwalamy zdarzenia w metodzie s ta r tS e r v ic e , podobnie jak to robiliśmy w poprzednim przykładzie. Pogrubione fragmenty kodu to części, które zostały dodane do kodu z poprzedniego listingu. Teraz dodam y adnotacje do części obserwującej. Tak jak poprzednio wystarczy tylko dodać kwalifikatory do odpowiedniej adnotacji @Observes.
Implementacja wzorca Obserwator w Javie EE I
import com .devchronicles.observer.javaee.M essageEvent.Type; @ Stateless public c la ss TraceObserver { public void serviceTrace( @Observes @MessageEvent(Type.SERVICE) S tring message) { System.out.println("W iadomość z usiugi: " + message); } public void parameterTrace( @Observes @MessageEvent(Type.PARAMETER) S tring message) { S y stem .o u t.p rin tln ("z parametrami: " + message); } Wyzwalanie i obserwowanie własnych typów obiektowych jest jeszcze prostsze. Typ obiektu nie może się powtarzać i nie trzeba tworzyć własnych kwalifikatorów adnotacyjnych. Wystarczy zamiast tego użyć obiektu. Obserwowalne zdarzenia są obsługiwane przez transakcje i dostarczane w transakcyjnej fazie, którą program ista zdefiniuje dla danego zdarzenia. Może to nastąpić przed zakończeniem lub po zakończeniu transakcji albo po udanej lub nieudanej transakcji. Poniżej przedstawiamy konkretny przykład. Na listingu 11.7 znajdują się definicje trzech metod obserwacyjnych określających fazę transakcji, podczas której obserwatory nasłuchują zdarzeń typu S trin g . Listing 11.7. Obserwator zdarzeń transakcji package com .devchronicles.observer; import jav ax .en terp rise.ev en t.O b serv es; import jav ax .en terp rise.ev en t.T ran sactio n P h ase; public c la ss TransactionEventObserver { public void onInProgress(@Observes S trin g message) { System .out.println("W tra k c ie : " + message); } public void onSuccess( @Observes(during = TransactionPhase.AFTER_SUCCESS) S tring message) { System .out.println("Pow odzenie: " + message); } public void onFailure( @Observes(during = TransactionPhase.AFTER_FAILURE) S tring message) { System .out.println("N iepow odzenie: " + message); } public void onCompletion( @Observes(during = TransactionPhase.AFTER_COMPLETION) S tring message) { System .out.println("Z akonczenie: " + message); } }
167
168
| ROZDZIAŁ 11. Wzorzec Obserwator
Jest pięć faz transakcyjnych — BEFORE_COMPLETION, AFTER_COMPLETION, AFTER_SUCCESS, AFTER_FAILURE oraz IN_PROGRESS (domyślna). Na listingu 11.7 nie zaimplementowaliśmy fazy BEFORE_COMPLETION. N atom iast na listingu 11.8 przedstawiamy implementację klasy demonstrującą wyzwolenie zdarzenia w przypadku powodzenia i porażki. Listing 11.8. Wywołania powodzenia i porażki package com .devchronicles.observer; import import import import import import import
javax.annotation.R esource; javax.ejb.S essionC ontext; ja v a x .e jb .S ta te le s s ; ja v a x .e jb .T ran sac tio n A ttrib u te ; jav ax .ejb .T ran sactio n A ttrib u teT y p e; ja v a x .e n te rp rise.e v e n t.E v e n t; ja v a x .in je c t.I n je c t;
@ Stateless @TransactionAttribute(TransactionAttributeType.REQUIRED) public c la ss Children { @Resource SessionContext sc; @Inject Event message; in t[ ] children = new in t[ 3 ] ; public void getSixthC hild() { tr y { in t sixthC hild = ch ild re n [5 ]; / / Zgłasza wyjątek IndexOutOfBounds. } catch (Exception e) { m essag e.fire("zd arzen ie wycofania"); System .out.println("Przechw ycono w y jątek"); sc.setR ollbackO nly(); } } public void getThirdC hild() { in t th ird C h ild = ch ild re n [2 ]; // powodzenie m essag e.fire("zd arzen ie powodzenia"); } } Klasa C hild ren symuluje udaną transakcję w metodzie g etT h ird C h ild i nieudaną transakcję w metodzie g e tS ix th C h ild przez zgłoszenie wyjątku IndexOutOfBounds. Przeanalizujemy każdą z tych metod, aby dowiedzieć się, w jaki sposób obserwowane są zdarzenia. M etoda g etT h ird C h ild zgłasza zdarzenie typu S trin g , przekazuje m u wiadomość zd arzen ie powodzenia i pomyślnie kończy działanie. Oto wynik wywołania tej metody: W tra k c ie : zdarzenie powodzenia Zakończenie: zdarzenie powodzenia Powodzenie: zdarzenie powodzenia M etoda o n InP rogress jest wywoływana natychm iast po wystąpieniu zdarzenia i w czasie, gdy transakcja jeszcze trwa. Pozostałe dwie m etody — onCompletion i onSuccess — muszą poczekać, aż transakcja dojdzie odpowiednio do faz AFTER_COMPLETION i AFTER_SUCCESS.
Gdzie i kiedy używać wzorca Obserwator
| 169
Następnie przyjrzymy się metodzie g etS ix th C h ild , która ulega awarii przez zgłoszenie wyjątku IndexOutOfBoundsException. Poniżej znajduje się wynik jej działania: W tra k c ie : zdarzenie wycofania Przechwycono wyjątek Zakończenie: zdarzenie wycofania Niepowodzenie: zdarzenie wycofania Tak jak poprzednio następuje natychmiastowe wywołanie m etody onInP rogress i metody onCompletion oraz o n F a ilu re m uszą zaczekać na jej zakończenie. Gdy m etoda onInP rogress wyświetli napis Przechwycono wyj ą te k i transakcja zostanie oznaczona do wycofania przez wywołanie m etody setR ollbackO nly interfejsu S essionC ontext, m etoda onInP rogress kończy działanie i m ożna wykonać kod obserwatorów. Następuje wykonanie m etody onCompletion, a po niej — m etody o n F ailu re. M etoda setR ollbackO nly oznacza bieżącą transakcję do wycofania, przez co transakcja ta nigdy nie zostanie zatwierdzona. Powoduje to wprowadzenie transakcji w fazę AFTER_FAILURE i wywołanie metody o n F ailu re. Obserwatory mogą też działać warunkowo, choć możliwości w tym zakresie ograniczają się do powiadamiania ich o tym, czy w bieżącym kontekście istnieje już egzemplarz ziarna definiującego metodę obserwacyjną. M etoda ta jest wywoływana tylko wtedy, gdy ten egzemplarz istnieje. Aby zdefiniować metodę obserwacyjną jako warunkową, należy dodać do adnotacji @Observes argum ent n o tify O b se rv e r = Reception.IF_EXISTS. import jav ax .en terp rise.ev en t.R ecep tio n ; public void addMember ( @Observes(notifyObserver = Reception.IF_EXISTS) S tring message){ / / im plem entacja
} Jeśli egzemplarz nie istnieje, to domyślnie zostaje utworzony.
Gdzie i kiedy używać wzorca Obserwator W zorzec Obserwator pozwala zoptymalizować wydajność program u poprzez rozluźnienie powiązań między składnikami systemu i zmianę kierunku relacji wywołanie-nasłuchiwanie. Podczas projektowania program u lub modyfikowania istniejącej aplikacji należy uważać na niepotrzebne regularne wywołania m etod będących dobrymi kandydatkami do zaimplementowania przy użyciu wzorca Obserwator. W Javie EE można bardzo łatwo przerobić istniejący kod tak, aby wykorzystać w nim wzorzec Obserwator. Obserwatorom w tej technologii zazwyczaj towarzyszą wstrzykiwanie zależności, implementowane przy użyciu adnotacji @ Inject, i fabryki, implementowane przy użyciu adnotacji @Produces. Największa zaleta wzorca Obserwator — luźne powiązanie klas — jest zarazem jego największą wadą. Jako że kontrolę sterowania przekazuje się z obiektu obserwowanego do obserwatora, traci się kontrolę nad przepływem sterowania w aplikacji. Trudniej jest połapać się we wzajemnych wywołaniach zdarzeń. Skomplikowana implementacja wzorca Obserwator może sprawiać mnóstwo problemów diagnostycznych i dlatego należy dążyć do jak najprostszych rozwiązań. Lepiej nie tworzyć zbyt wielu warstw obserwatorów — wystarczy jedna lub co najwyżej kilka. Aby ułatwić przyszłym i obecnym program istom zrozumienie sposobu działania naszego kodu, obserwatorom należy nadawać nazwy zgodne z ich przeznaczeniem. Ponadto w nazwach metod pow inna znajdować się informacja o celu prowadzenia obserwacji.
170
I
ROZDZIAŁ 11. Wzorzec Obserwator
Jeśli w swoim kodzie masz zmieniający się podm iot i składniki wykorzystujące dane tego podm iotu, nie wahaj się zastosować wzorca Obserwator. Obserwatory transakcyjne zapewniają funkcjonalność, jakiej w starszych wersjach technologii nie było. W fazie BEFORE_COMPLETION można anulować bieżącą transakcję za pom ocą wywołania metody se tR o llb a ckO n ly i w ten sposób umożliwić wykonanie nietransakcyjnych operacji w fazie transakcyjnej. Jeśli wystąpi wyjątek, następuje wycofanie całej transakcji. W fazie IN_PROCESS, która obejmuje całą transakcję, m ożna zgłaszać i obserwować zdarzenia. Można to wykorzystać do zaimplementowania m onitora postępu albo rejestratora dziennikowego. Wywołanie m etody obserwacyjnej blokuje emisję zdarzeń i jest synchroniczne, ale m ożna je zmienić na asynchroniczne za pom ocą adnotacji @Asynchronous. (Więcej informacji na temat sposobów użycia tej adnotacji znajduje się w rozdziale 9., „Asynchroniczność”). Szczególną ostrożność należy zachować przy tw orzeniu asynchronicznych obserwatorów w fazie BEFORE_COMPLETION, ponieważ m etoda se tR o llb a ck O n ly jest nieefektywna i transakcja nie zostanie wycofana. M etoda asynchroniczna występuje w nowej transakcji.
Podsumowanie W tym rozdziale pokazaliśmy, jak zmieniła się rdzenna implementacja wzorca Obserwator w Javie EE 7 oraz jak go wykorzystywać w połączeniu z mechanizmami transakcyjnymi. Wzorzec Obserwator pozwala oddzielić logikę biznesową od obserwatora, dzięki czemu jedynymi powiązaniami tych składników są typ zdarzenia i kwalifikator. Wadą tego rozwiązania może być to, że nie widać relacji między elementami, chociaż da się temu zaradzić, stosując odpowiednie nazwy klas i metod oraz opisując powiązania w dokumentacji. Rozpoznawanie faz transakcji wzbogaca funkcjonalność wzorca Obserwator o nowe możliwości i pozwala zintegrować m etody obserwacyjne z transakcjami, aby w razie potrzeby wycofać wprowadzone przez nie zmiany.
ĆWICZENIA 1.
Wymień jak najwięcej implementacji wzorca Obserwator, które można znaleźć w języku Java.
2.
Napisz przykładowy kod z wykorzystaniem argumentu notifyObserver = Reception.IF_EXISTS w adnotacji @Observes.
3.
Wykorzystaj mechanizmy transakcyjne obserwatorów do monitorowania postępu transakcji i zarejestrowania wyniku transakcji w dzienniku (powodzenie lub niepowodzenie).
12 Wzorzec Dostęp do Danych
ZAWARTOŚĆ ROZDZIAŁU:_______ > pochodzenie wzorca projektowego Dostęp do Danych; > opis podobnego wzorca o nazwie Obiekt Transferu Danych; > połączenie wzorców DAO i Fabryka; > wprowadzenie do JPA i ORM; > prosta implementacja DAO; > ulepszona implementacja przy użyciu generyczności; > zastosowania DAO w nowoczesnym programowaniu w Javie EE.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r12, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. T rudno sobie wyobrazić aplikację biznesową, która nie wykorzystuje jakiegoś źródła danych. Może nim być: relacyjna lub obiektowa baza danych, baza danych typu NoSQL, repozytorium LDAP (ang. Lightweight Directory Access Protocol), system plików, usługa sieciowa albo system zewnętrzny. Niezależnie od źródła danych aplikacja musi skądś pobierać informacje oraz wykonywać podstawowe operacje tworzenia, pobierania, aktualizowania i usuwania danych. Prawie wszystkie serwery wykorzystują podobne rozwiązania do zapisywania danych sesji i długotrwałych procesów.
172
I
ROZDZIAŁ 12. Wzorzec Dostęp do Danych
Sposoby wykorzystania implementacji źródeł danych mogą być bardzo różne. Istnieje wiele dialektów języka SQL, np. PostgreSQL i Oracle. Celem stosowania wzorca O biekt D ostępu do D anych (ang. data access object — DAO) jest zapewnienie wygodnego w użyciu interfejsu dostępu do danych, z którego mogą korzystać różne warstwy programu. W tym rozdziale opisujemy pierwotny rodzaj problemów rozwiązywanych przez DAO i zastosowanie tego wzorca w Javie EE. Ponadto analizujemy rolę spokrewnionego wzorca D TO (ang. data transfer object — obiekt transferu danych) oraz to, jak razem z wzorcem Fabryka można go wykorzystać w połączeniu z DAO. W dalszej części rozdziału opisujemy też zastosowania JPA i ORM w kontekście DAO. Przedstawiamy implementację DAO i pokazujemy, jak ją ulepszyć przy użyciu mechanizmów generyczności. N a koniec dowiesz się, jak z czasem zmieniła się rola tego wzorca i dlaczego nadal się go używa.
Czym jest wzorzec Dostęp do Danych Pierwsze rozwiązanie oparte na wzorcu DAO zdefiniowano w książce J2EE. Wzorce projektowe. Wydanie drugie1 w następujący sposób: Używamy obiektów Data Access Object, aby ujednolicić i zawrzeć cały kod dostępu do trwałego magazynu danych. Obiekt Data Access Object zarządza połączeniem ze źródłem danych w celu pobierania i zapisywania danych. Abstrakcja i enkapsulacja źródła danych uniezależniły aplikację od implementacji tego źródła, a więc odłączyły logikę biznesową od implementacji źródła danych. Chodziło o to, by w razie zmiany sposobu przechowywania danych nie trzeba było niwelować negatywnego wpływu tej czynności na program. Ale w rzeczywistości źródło danych zmienia się bardzo rzadko, nawet między dostawcami tego samego typu, jak np. PostgreSQL i MS SQL. Trudno sobie wyobrazić kogoś, kto decyduje się na zmianę np. źródła SQL na system płaskich plików XML, repozytorium LDAP albo usługę sieciową. Takie rzeczy po prostu się nie zdarzają. Jaką wartość w takim razie m a wzorzec DAO w nowoczesnej Javie EE? Czy w ogóle jest potrzebny? Tak, wzorzec DAO wciąż jest potrzebny, i to w pierwotnej postaci, chociaż zmienił się główny cel jego implementowania. Programista nie tyle chce się chronić przed niekorzystnymi konsekwencjami mało prawdopodobnej zmiany źródła danych, ile móc wykorzystać dodatkowe mechanizmy tworzenia atrap obiektów i testowania oraz oczyścić kod z mechanizmów dostępu do danych. Obecnie wzorzec DAO stosuje się w celu opakowywania starych systemów przechowywania informacji i uproszczenia dostępu do skomplikowanych implementacji źródeł danych. Ale są to raczej rzadkie przypadki. Wzorzec DAO opakowuje operacje CRUD (ang. create, read, update, delete — tworzenie, odczyt, aktualizacja, usuwanie) w interfejs implementowany przez konkretną klasę. W razie potrzeby można łatwo utworzyć atrapę obiektu implementującego ten interfejs, co ułatwia testowanie przez eliminację konieczności rzeczywistego łączenia się z bazą danych. Konkretna implementacja DAO do wykonywania operacji CRUD wykorzystuje niskopoziomowe interfejsy API, takie jak JPA i Hibernate.
Diagram klas Dostępu do Danych Na rysunku 12.1 przedstawiono diagram klas wzorca DAO przedstawiający interakcje między klientem i DAO oraz DTO. Na diagramie nie ukazano fabryki tworzącej egzemplarz DAO. 1 D eepak A lur, John C rupi, D an M alks, J2EE. W zorce projektowe. W ydanie drugie, H elion, 2004.
Ogólne informacje o wzorcu Dostęp do Danych
| 173
Rysunek 12.1. Diagram klas wzorca Dostęp do Danych
Ogólne informacje o wzorcu Dostęp do Danych Implem entacja wzorca DAO składa się z kilku części: ^
interfejs DAO,
^
konkretna implementacja interfejsu DAO,
^
fabryka DAO,
^
obiekt DTO.
Fabryka, interfejs i obiekt DTO to składniki opcjonalne, ale często używane w połączeniu z wzorcem DAO. Bardziej szczegółowy opis wzorca projektowego Fabryka znajduje się w rozdziale 6., „Wzorzec Fabryka”.
Wzorzec Obiekt Transferu Danych Obiekt DTO przenosi dane pobrane z bazy danych lub zapisywane w bazie danych przez różne warstwy logiczne. Na przykład aby przesłać listę obiektów typu User pobraną z warstwy dostępu do danych do warstwy sieciowej, warstwa usługowa musiałaby przesłać dane z DAO do DTO. UWAGA Obiekt DTO czasami nazywany jest też obiektem wartości (ang. value object). Rozwiązanie proponow ane przez wzorzec DTO jest opisane w książce J2EE. Wzorce projektowe. Wydanie drugie i wygląda następująco: Do przeniesienia wielu elementów danych przez warstwę wykorzystaj obiekt transferowy. Obiekt DTO redukuje liczbę zdalnych żądań sieciowych, które powodują wywołania m etod ziaren, co przyczynia się do zwiększenia wydajności program u. Czasami nie wszystkie dane pobrane z bazy danych są potrzebne w warstwie sieciowej lub innej, w której się ich używa. Obiekt DTO ogranicza transfer danych tylko do tych, które są potrzebne, i w ten sposób optymalizuje przesyłanie informacji między warstwami. W tym rozdziale nie opisujemy szczegółowo obiektu DTO, ale zalecamy przeczytanie poświęconego m u rozdziału z książki J2EE. Wzorce projektowe. Wydanie drugie.
174
I
ROZDZIAŁ 12. Wzorzec Dostęp do Danych
API JPA i ORM Interfejs API JPA (ang. Java Persistence API) służy do kontrolowania interakcji program u ze źródłem danych. Określa sposób dostępu do informacji, zapisywania ich oraz zarządzania nim i między obiektami i źródłem. Sam interfejs JPA nie pozwala na wykonywanie operacji CRUD ani żadnych innych związanych z obsługą danych. Jest to tylko zestaw interfejsów i wymogów implementacyjnych, ale każdy serwer zgodny z Javą EE musi go obsługiwać. Specyfikacja JPA zastępuje specyfikację Container-Managed Persistence (CMP) EJB 2.0, która była nadm iernie rozbudow ana i skom plikowana. Technologia CMP spotkała się z nieprzychylnym przyjęciem w środowisku program istów , czego skutkiem było powszechne odejście do innych rozwiązań, takich jak Hibernate czy TopLink. W efekcie powstała specyfikacja JPA (opublikowana wraz z EJB 3.0). Jej celem było pogodzenie CMP, Hibernate i TopLink i wygląda na to, że się udało. Sercem JPA jest pojęcie encji (ang. entity). W technologii CMP nazywało się to ziarnem encyjnym (ang. entity bean). Encja to krótkotrwały obiekt, który można zapisać w bazie danych — nie jako obiekt poddany serializacji, lecz jako dane. Jest to obiekt POJO, którego składowe są opatrzone adnotacjami i mapowane na pola w źródle danych. Najłatwiej to wyjaśnić na konkretnym przykładzie kodu. Poniżej znajduje się definicja klasy encji Movie jako POJO z odpowiednimi adnotacjami: @Entity public c la ss Movie { @Id @GeneratedValue p riv a te Long i d ; p riv a te S trin g t i t l e ; p riv a te S trin g d e s c rip tio n ; p riv a te F loat p r ic e ; public Movie(){} / / D la uproszczenia pom in ięto m etody pobierające i ustawiające.
} Jest to prosta klasa z tylko trzem a adnotacjami. Adnotacja klasowa @ Entity wskazuje, że klasę tę należy traktow ać jako klasę encyjną, a adnotacje @Id i @Generated oznaczają składową id jako automatycznie generowane pole identyfikacyjne. Oznacza to, że podczas zapisywania encji pole id zostanie automatycznie wygenerowane zgodnie z zasadami automatycznego generowania pól obowiązującymi w źródle danych. Jeżeli tym źródłem jest baza danych, to wszystkie pola z encji zostaną zapisane w tabeli o nazwie Movie. Nie trzeba stosować żadnych dodatkowych adnotacji do oznaczania, które pola mają zostać zapisane. Taki sposób m apowania nazywa się m apow aniem obiektowo-relacyjnym (ang. Object-Relational Mapping — ORM). W tym rozdziale nie m a miejsca na szczegółowy opis JPA i ORM, więc zalecamy przeczytanie ósmej części kursu programowania w Javie EE 72.
Implementacja wzorca Dostęp do Danych w Javie EE Poniżej przedstawiamy przykład implementacji DAO w Javie EE. W ykorzystamy domenę wypożyczalni film ów i źródło danych w postaci relacyjnej bazy danych. Najpierw utworzymy klasę encyjną filmów, którą oznaczymy odpowiednimi adnotacjami JPA, jak pokazano na listingu 12.1. 2 The Java EE 7 Tutorial: P art V I I I Persistence, http://docs.oracle.com /javaee/7/tutorial/partpersist.htm .
Implementacja wzorca Dostęp do Danych w Javie EE
Listing 12.1. Klasa encyjna filmów
package com.devchronicles.dataaccessobject; import import import import
java.io.Serializable; javax.persistence.Entity; javax.persistence.Id; javax.persistence.NamedQuery;
@Entity public class Movie implements Serializable { private st at i c fi nal long serialVersionUID = -6580012241620579129L; @Id @GeneratedValue private int id; private String t i t l e ; private String description; private int price; / / ja k a ś w artość u żyw a n a w czasie działania program u, której nie trzeba zapisyw ać
@Transient private int runtimeId; public Movie() {} public int getId() { return t hi s. id; } public void setId(int id) { t h i s . i d = id; } public String getTitle() { return t h i s . t i t l e ; } public void setTitle(String t i t l e ) { th is.title = title; } public String getDescription() { return this.description; } public void setDescription(String description) { this.description = description; } public int getPrice() { return this.price; } public void setPrice(int price) { t hi s . pri ce = price; } public int getRuntimeId() {
| 175
176
I
ROZDZIAŁ 12. Wzorzec Dostęp do Danych
return this.runtimeId; } public void setRuntimeId(int runtimeId) { this.runtimeId = runtimeId; } } Przedstawiona klasa reprezentuje zwykłe obiekty Javy opatrzone adnotacjami JPA. Jak wspomnieliśmy wcześniej, adnotacja klasowa @Entity oznacza, że klasę należy traktować jako encyjną i powinien nią zarządzać dostawca m echanizm u zapisywania danych. Klasa encyjna musi mieć konstruktor bezargumentowy, który może być publiczny lub chroniony, ale może obok niego zawierać także inne konstruktory. Musi to być klasa najwyższego poziomu, tzn. nie może być wyliczeniem ani interfejsem oraz nie może być finalna. Ponadto finalna nie może być żadna z trwałych zmiennych egzemplarzowych ani m etod pobierających i ustawiających klasy encyjnej. Klasa encyjna musi implementować interfejs S e r i a l i z a b l e . Składową id oznaczyliśmy adnotacjami @Id i @GeneratedValue, które definiują ją jako automatycznie generowany klucz główny. Wszystkie encje muszą mieć klucz główny, który może być pojedynczą składową lub kombinacją składowych. Klucz główny może być jednego z następujących typów: ^
Podstawowy typ Javy — byte, char, short, i n t , long.
^
Klasy opakowaniowe podstawowych typów Javy — Byte, Character, Short, Integer, Long.
^
Tablice typów podstawowych lub ich opakowań — l o n g [ ] , Long [] itd. Typy Javy — String, BigInteger, Date.
Wszystkie składowe klasy encyjnej są automatycznie mapowane na pola o takich samych nazwach w tabeli movie, chyba że zostaną opatrzone adnotacją @Transient. Oznacza to, że składowa id w tabeli movie zostanie odwzorowana na pole i d, t i t l e na t i t l e itd. N a listingu 12.2 tworzymy interfejs DAO. Powinien on definiować podstawowe m etody CRUD i inne, które mogą być przydatne. Listing 12.2. Interfejs DAO package com.devchronicles.dataaccessobject; import j ava. ut il. Lis t; public interface MovieDAO { public void addMovie(Movie movie); public Movie getMovie(int i d ) ; public void deleteMovie(int id); public void updateMovie(Movie movie); public List getAllMovies(); } Teraz przechodzimy do konkretnej implementacji interfejsu DAO przedstawionej na listingu 12.3. Definiujemy w niej operacje CRUD. Zwróć uwagę, że konstruktor przyjmuje egzemplarz typu EntityManager. Obiekt ten jest powiązany z kontekstem zapisywania zdefiniowanym w pliku persistence.xml. Interfejs API EntityManager zapewnia funkcje do tworzenia, usuwania i zapisywania danych oraz możliwość tworzenia zapytań. Pola przejściowe nie są zapisywane w bazie danych, więc po każdym utworzeniu obiektu ich wartości są zerowane.
Implementacja wzorca Dostęp do Danych w Javie EE
I
177
Listing 12.3. Implementacja interfejsu DAO
package com.devchronicles.dataaccessobject; import j ava. ut il. Lis t; import javax.persistence.EntityManager; public class MovieDAOImpl implements MovieDAO{ private EntityManager em; public MovieDAOImpl(EntityManager em) { this.em = em; } @Override public void addMovie(Movie movie) { em.persist(movie); } @Override public Movie getMovie(int id) { return getAllMovies().get(id); } @Override public void deleteMovie(int id) { em.remove(getMovie(id)); } @Override public void updateMovie(Movie movie) { em.merge(movie); } @Override public List getAllMovies() { return em.createQuery("SELECT m FROM Movie m", Movie.class) . getResultList(); } } N a listingu 12.4 tworzymy fabrykę DAO. Najpierw budujem y obiekt typu EntityManager, który wstrzykujemy do tej klasy, a następnie przekazujemy go jako argum ent konstruktora do m etody createMovieDAO tworzącej obiekt DAO. Opis wzorca Fabryka znajduje się w rozdziale 6., więc jeśli potrzebujesz odświeżenia pamięci, możesz do niego wrócić. Listing 12.4. Fabryka DAO package com.devchronicles.dataaccessobject; import import import import
javax.enterprise.context.ApplicationScoped; javax.enterprise.inject.Produces; javax.persistence.EntityManager; javax.persistence.PersistenceContext;
178
| ROZDZIAŁ 12. Wzorzec Dostęp do Danych
@ApplicationScoped public class MovieDAOFactory { @PersistenceContext(unitName="moviePU") private EntityManager em; @Produces public MovieDAO createMovieDAO() { return new MovieDAOImpl(em); } } Lista encji w aplikacji nazywa się jednostką utrw alania (ang. persistence unit ) , którą definiuje się w pliku konfiguracyjnym persistence.xml. Plik ten powinien znajdować się w katalogu M ETA-INF aplikacji. Poniżej znajduje się opis jego najważniejszych części. ^
Nazwa jednostki utrw alania — jednostce utrwalania m ożna nadać nazwę, jeśli planuje się zdefiniować kilka takich jednostek i wybierać je w czasie działania programu.
^
Typ transakcji jednostki trw ałości — w aplikacjach Java SE domyślny typ transakcji to RESOURCE_LOCAL, natom iast w środowisku Java EE typ transakcji to JTA. Oznacza to, że w transakcji uczestniczy m enedżer encji.
^
Dostaw ca — ten element identyfikuje klasę dostarczającą fabrykę do tworzenia egzemplarzy EntityManager.
^
Klasa — w tym elemencie pow inny być wymienione klasy encyjne wykorzystywane w aplikacji.
^
W łasność — m ożna definiować dodatkowe własności, np. połączenia z bazą danych i z dostawcą m echanizm u utrwalania.
EntityManager jest powiązany z kontekstem utrwalania zdefiniowanym w pliku persistence.xml, którego zawartość pokazano na listingu 12.5. Listing 12.5. Treść pliku persistence.xml org.eclipse.persistence.jpa.PersistenceProvider jdbc/sample com.devchronicles.dataaccessobject.Movie W pliku persistence.xml określa się konkretne źródło danych. W tym przypadku zdefiniowano bazę danych Derby przy użyciu dostawcy łącza eclipse. Typ transakcji ustawiono na JTA, ponieważ jest to implementacja aplikacji Java EE, a jako klasę encyjną wyznaczono com.devchronicles.dataaccessobject.Movie. N a koniec musim y jeszcze wstrzyknąć utworzony obiekt DAO w odpowiednie miejsce. Przedstawiony na listingu 12.6 klient pobiera egzemplarz wstrzykniętego obiektu DAO i wykorzystuje go do pobrania wszystkich filmów.
Implementacja wzorca Dostęp do Danych w Javie EE
I
179
Listing 12.6. Klient package com.devchronicles.dataaccessobject; import javax.ejb.Stateless; import javax.inject.Inject; import j ava. ut il. Lis t; @Stateless public class Client { @Inject MovieDAO movieDAO; public List getAllMovies() { return movieDAO.getAllMovies(); } } Przedstawiona implementacja DAO jest znacznie uproszczona i można ją ulepszyć na wiele sposobów.
Implementacja DAO bezpieczna pod względem typów Jednym ze sposobów ulepszenia przedstawionej implementacji DAO jest zabezpieczenie interfejsu DAO pod względem typów. Pozwala to na utworzenie bezpiecznego pod względem typów interfejsu DAO, który mógłby implementować podinterfejs dla każdego typu encji, jaki chcemy utrwalić. Podstawowy obiekt DAO może wyglądać tak, jak pokazano na listingu 12.7. Listing 12.7. Podstawowy DAO bezpieczny pod względem typów package com.devchronicles.dataaccessobject; import j ava. ut il. Lis t; public interface BaseDAO { public void create(E entity); public Movie retrieve(K id); public void update(E entity); public void delete(K i d ) ; } Pierwszy param etr typu, E, reprezentuje encję, natom iast param etr typu Ksłuży jako klucz. Podinterfejs definiujący m etody specyficzne dla tej encji mógłby rozszerzać interfejs BaseDAO. Na listingu 12.8 tworzymy interfejs rozszerzający BaseDAO i definiujący metodę zwracającą listę wszystkich filmów. Listing 12.8. Implementacja podstawowego interfejsu DAO package com.devchronicles.dataaccessobject; import j ava. ut il. Lis t; public interface MovieDAO extends BaseDAO{ public List findAllMovies(); } Konkretna klasa pow inna implementować ten interfejs i wszystkie metody.
180
I
ROZDZIAŁ 12. Wzorzec Dostęp do Danych
Gdzie i kiedy używać wzorca Dostęp do Danych Niektórzy twierdzą, że wzorzec DAO nie jest już potrzebny, ponieważ m ożna bez problemu bezpośrednio wywoływać EntityManager. Jest to dobry argument, ponieważ EntityManager zapewnia interfejs API reprezentujący warstwę dostępu do danych. Ponadto m ożna bezpiecznie założyć, że raz wybrany dostawca danych raczej się nie zmieni, w związku z czym abstrakcja zapewniana przez DAO staje się mało przydatna. A jednak mimo tych niewątpliwie trafnych argumentów DAO nadal m a swoją niszę w dobrze zaprojektowanych aplikacjach Java EE (i niekoniecznie jest to ta sama nisza, którą zajmował pierwotnie). Zaletą rozszerzania podstawowego interfejsu BaseDAO pokazanego na listingu 12.7 dla każdego typu encji jest rozszerzalność każdej implementacji. Metody specyficzne dla danej encji można pisać, zachowując wspólny interfejs. Implementację DAO dla każdej encji wybiera się raz, zamiast wybierać odpowiednią metodę EntityManager za każdym razem, gdy trzeba zapisać lub pobrać dane. Nazwane zapytania można wstawić do encji, których dotyczą. Dzięki tem u zapytania znajdują się w miejscu, do którego logicznie należą, co ułatwia ich obsługę serwisową. DAO zapewnia jednolity i kontrolowany dostęp do danych, ponieważ przechodzą przez niego wszystkie operacje dostępu do danych. Stanowi to realizację zasady pojedynczej odpowiedzialności, ponieważ tylko DAO ma dostęp do danych aplikacji. Poza tym nie m ożna zapominać, że mimo iż ryzyko zmiany sposobu przechowywania informacji jest niewielkie, to jednak istnieje. Jeśli do tego dojdzie, dodatkowa warstwa abstrakcji z pewnością będzie Cię cieszyć.
Podsumowanie Wzorzec DAO m a wielu zwolenników i przeciwników. Decyzję, czy użyć go w swojej aplikacji, należy podjąć na podstawie wymagań. Tak jak w przypadku wszystkich wzorców, stosowanie DAO tylko dlatego, że się to potrafi, jest bardzo złym pomysłem i może doprowadzić do komplikacji kodu, który przez to stanie się kompletnie niejasny. Postaraj się dobrze zrozumieć różne implementacje tego wzorca i sposoby jego interakcji z DTO oraz z fabrykami.
ĆWICZENIA 1.
Napisz interfejs i jego implementację dla DAO zamówień filmów. Na początek możesz wykorzystać przykłady z tego rozdziału.
2.
Napisz fasadę usługi i DTO wykorzystujące interfejs MovieDAO.
13 REST-owe usługi sieciowe
ZAWARTOŚĆ ROZDZIAŁU:_______ > REST; > sz e ść w a ru n k ó w REST; > m o d e l d o jrza ło śc i R ich a rd so n a API ty p u REST; > ja k za p ro je k to w a ć R E S T -o w y in te rfe js API; > R E ST w akcji; > ja k za im p le m e n to w a ć R E ST w Ja v ie EE; > H A T E O A S — n a jw y ż s z y p o z io m w m o d e lu d o jrza ło ści R ich a rd so n a .
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r13, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału. Praktycznie wszyscy znają pojęcie REST, ale nie każdy dokładnie wie, co ono oznacza i jak to się implementuje. Wiele osób mających tylko mgliste pojęcie o tej technologii stwierdzi, że strona internetow a musi „spełniać wymagania” REST i że bez tego nie uda się jej przetrwać w internecie. Dla wszystkich tych osób REST to tylko slogan. N atomiast dla specjalistów jest to nazwa bardzo ważnej technologii. Co w takim razie kryje się za tą nazwą i skąd się ona wzięła? REST to akronim angielskich słów REpresentational State Transfer, określający architektoniczny styl reprezentowania i przesyłania danych. Składa się on z sześciu warunków dotyczących danych, składników i ich interakcji w obrębie rozproszonego systemu hipermedialnego (internetu).
182
I
ROZDZIAŁ 13. REST-owe usługi sieciowe
Technologia REST nie jest związana z żadnym protokołem (choć prawie zawsze jest używana w połączeniu z HTTP) i nie została ustandaryzowana przez organizację W3C. Jest zatem zbiorem konwencji, stylów i technik, które wypracowano i uzgodniono przez lata praktyki. Term in REST ukuł w 2000 r. Roy Fielding w swojej pracy doktorskiej pt. Style architektoniczne i projektowanie architektury aplikacji sieciowych1. Jego koncepcja została podchwycona przez innych program istów i architektów oraz zyskała tak wielką popularność, że stała się integralną częścią wielu języków i systemów szkieletowych. Na przykład język Ruby zapewnia naturalne mechanizmy do posługiwania się trasami REST-owymi, a system szkieletowy Spring dostarcza uproszczone m etody implementacji w arunku HATEOAS (ang. Hypermedia as the Engine of Application State), który jest trzecim poziom em modelu dojrzałości Richardsona obsługi REST (temat ten rozwijamy nieco dalej)2. Technologię REST zazwyczaj przedstawia się jako rozwiązanie architektoniczne, a nie wzorzec projektowy. Niemniej jednak technologia ta powstała w celu rozwiązania pewnych problemów powszechnie spotykanych w aplikacjach biznesowych, a więc pod tym względem przypomina wzorce projektowe.
Co to jest REST REST m a wiele definicji, a dyskusje na ich tem at często są wyłącznie teoretyczne. W tym rozdziale reprezentujem y punkt widzenia programisty, który chce zaimplementować REST-owy interfejs API dla forum m iłośników kina.
SŁOWA ROYA FIELDINGA REST kładzie nacisk na skalowalność interakcji między składnikami, ogólność interfejsów, niezależność wdrażania składników oraz składniki pośrednie w celu zredukowania opóźnień w interakcjach, zapewnienia bezpieczeństwa oraz opakowania przestarzałych systemów. Z praktycznego punktu widzenia REST m ożna traktować jako styl formatowania identyfikatorów URI reprezentujących zasoby (dane) dostarczane i przechowywane przez aplikację. Czym są zasoby? W przypadku forum internetowego może być wiele rodzajów zasobów, np. użytkownicy i ich wpisy. Zasoby te są reprezentowane przez rzeczowniki i wykorzystywane w połączeniu z m etodam i HTTP do tworzenia REST-owych identyfikatorów URI. Na przykład zasób konta można reprezentować przy użyciu identyfikatora URI /accounts. Przy użyciu m etody HTTP GET m ożna sprawić, aby żądania wysyłane na ten URI zwracały informacje o wszystkich kontach. Podobnie pojedynczy zasób konta można reprezentować przez dołączenie identyfikatora wpisu do URI, np. / ac c oun t s / :id. Żądanie GET wysłane do tego URI zwróci dane konta o określonym identyfikatorze. Przy użyciu URI REST-owych m ożna nie tylko pobierać zasoby, ale też je tworzyć. W tym celu należy utworzyć URI przy użyciu m etody HTTP POST. Aby np. utworzyć nowe konto, należy wysłać żądanie POST do URI /accounts i w treści tego żądania przesłać dane potrzebne do wygenerowania zasobu.
1 Roy Fielding, A rchitectural Styles a n d the Design o f N etw ork-B ased Softw are A rchitectures, 2000, ro zdział 5, http://w w w .ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm . 2 L eonard R ichardson w yjaśnił m odel dojrzałości REST n a ko n fe re n c ji Q C o n w 2008 r.; http://w w w .crum m y.com /w riting/speaking/2008-Q C on/act3.htm l.
Sześć warunków REST | 183
Jak już wiesz, URI reprezentuje zasób na zdalnym serwerze, a m etoda (HTTP), przy użyciu której wysłano żądanie, decyduje o tym, jakie działania zostaną wykonane w odniesieniu do tego zasobu. Niektórych może kusić pomysł powiązania metod HTTP z operacjami CRUD (tworzenie, pobieranie, aktualizowanie i usuwanie) w ten sposób, że m etoda POST służy do tworzenia, GET do odczytywania zasobów itd.3. Ale to nie jest w duchu REST i nie pomaga w zrozumieniu reprezentacji zasobów. Już bliżej tem u pomysłowi do technologii zdalnych wywołań procedur (RPC), która znajduje się na zerowym poziomie modelu dojrzałości Richardsona. Nas interesuje tylko implementacja REST na najwyższym, trzecim poziomie tego m odelu (jego szczegółowy opis znajduje się w podrozdziale „Model dojrzałości Richardsona”). REST-owy interfejs API nie opisuje czynności, tylko „rzeczy”, a dokładniej rzeczowniki reprezentujące zasoby. Zatem będziem y posługiw ać się zasobam i reprezentującym i wpisy, użytkow ników i adresy zam iast czasownikowymi m etodam i typu: g e t U s e r , a d d P o s t i d e l e t e A d d r e s s . REST różni się pod tym względem od technologii SOAP i RPC, które skupiają się na czynnościach wykonywanych na danych aplikacji. W sensie REST-owym wywołuje się URI przy użyciu odpowiedniej m etody HTTP. Każdy zasób jest identyfikowany przez URI. Jeden zasób może być osiągalny na wiele sposobów, dzięki czemu m ożna się do niego dostać z różnych miejsc. Na przykład zasób reprezentujący użytkownika m ożna pobrać bezpośrednio, wysyłając żądanie m etodą GET na adres / u s e r s / : i d albo przechodząc do listy użytkowników obserwujących innego użytkownika — GET / u s e r / : i d 1 / f o l l o w e r s / : i d 1 . Reprezentacja zasobu nie jest samym zasobem, więc nie m a żadnych przeszkód, aby jeden zasób miał wiele reprezentacji. Reprezentacje zasobów przepływają w obie strony między serwerem i klientem i reprezentują przynajmniej część stanu zasobu. Dzięki tem u reprezentacja zawiera wystarczająco dużo informacji, aby m ożna było utworzyć, zmodyfikować lub usunąć zasób. Zasoby są zazwyczaj prezentowane w formacie JSON (ang. JavaScript Object Notation) lub XML (ang. Extensible M arkup Language), ale równie dobrze może to być dowolny inny format, także własnościowy.
Sześć warunków REST Roy Fielding w swojej pracy doktorskiej napisał, że prawdziwie REST-owa architektura musi spełniać pięć z sześciu opisanych przez niego warunków. W arunki te nazywa się stylem REST.
Klient-serwer W arunek klient-serwer opiera się na zasadzie rozdziału obowiązków i definiuje wyraźny rozdział klienta od serwera. W ymóg ten jest bardzo prosty i nakazuje, aby klient wysyłał żądanie, a serwer je odbierał. W razie potrzeby serwer może odpowiedzieć na odebrane żądanie.
3 S ta n d ard RFC H T T P/1.1 zaw iera definicje n astępujących m etod: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE oraz CONNECT.
184
| ROZDZIAŁ 13. REST-owe usługi sieciowe
Jednolity interfejs Ten warunek oznacza, że między serwerem i klientem powinien znajdować się maksymalnie ogólny i prosty interfejs. Wiesz już, że zasób jest reprezentacją danych, a klient nie m a do nich bezpośredniego dostępu. Ograniczenie to definiuje sposób reprezentacji tego zasobu przez rzeczowniki oraz nakazuje, aby zarządcą interfejsu był twórca systemu danych. Ma to zapewnić względną niezmienność interfejsów w czasie. W arunek nie nakazuje wykorzystywania protokołu HTTP, ale prawie zawsze używany jest właśnie ten protokół. Jak już wiesz, jeśli używana jest specyfikacja HTTP, URI tworzy się z rzeczowników oznaczających nazwy zasobów i czasowników HTTP.
Bezstanowość Serwer nie powinien przechowywać stanu klienta, tzn. każda wiadomość w żądaniu powinna być całkowicie wystarczająca, a więc powinna zawierać wystarczająco dużo informacji kontekstowych, aby serwer mógł ją odpowiednio przetworzyć. Oznacza to, że jeśli jest jakiś stan, to jego zarządcą jest klient. Zaletą tego w arunku jest zwiększenie poziom u skalowalności, niezawodności i widoczności. Natomiast wadą jest pogorszenie wydajności, ponieważ do podtrzymywania komunikacji bezstanowej potrzebne są obszerniejsze wiadomości.
Możliwość zapisywania danych w buforze Odpowiedzi serwera musi dać się buforować. Interfejs REST-owy powinien zapewniać mechanizm do zaznaczania, czy dana wiadomość może być przechowywana w buforze, czy nie. Może to być jawne, niejawne albo podlegać negocjacji.
System warstwowy Klient nie może zakładać, że będzie m iał bezpośredni dostęp do serwera. Może otrzymać odpowiedź z bufora albo bezpośrednio z serwera. Poprawia to skalowalność, ponieważ między klientem i serwerem mogą występować pośrednie warstwy programowe lub sprzętowe.
Kod na żądanie Ten warunek definiuje architekturę REST jako hierarchię warstw, które mogą komunikować się tylko ze swoimi najbliższymi sąsiadami. Taki rozdział spraw upraszcza architekturę oraz izoluje od siebie bardzo różne i przestarzałe komponenty. Największą korzyścią z tego jest zwiększenie skalowalności, ponieważ m ożna łatwo dodawać nowe składniki i wymieniać stare. W adą natomiast jest pogorszenie wydajności systemu wynikające z wprowadzenia dodatkowych warstw pośredniości. Ten warunek pozwala klientowi pobierać i wykonywać kod z serwera, co z kolei umożliwia serwerowi tymczasowe rozszerzanie funkcjonalności klienta przez przekazywanie m u logiki. Logika ta może być np. w formie kodu JavaScript. W arunek kodu na żądanie jest jako jedyny opcjonalny. Złamanie którejkolwiek z wymienionych zasad (nie licząc kodu na żądanie) powoduje, że usługa nie jest, ściśle rzecz biorąc, REST-owa. Ale to oczywiście nie oznacza, że aplikacja od razu staje się bezużyteczna.
Model dojrzałości Richardsona
I
185
Model dojrzałości Richardsona Wcześniej napisaliśmy, że prawdziwy REST-owy interfejs API osiąga trzeci poziom w modelu dojrzałości Richardsona. Teraz przyjrzymy się nieco bliżej wszystkim poziomom tego modelu. Leonard Richardson podjął próbę sklasyfikowania interfejsów API według poziom u ich zgodności z warunkam i technologii REST. Im większa zgodność implementacji, tym lepiej. W yróżnił cztery poziomy. Pierwszy to poziom 0., który oznacza implementacje o niewielkim stopniu zgodności z REST, a poziom 3. to najwyższy stopień zgodności4.
Poziom 0. — zwykły XML W tym modelu do wykonywania zdalnych wywołań wykorzystuje się protokół transportowy HTTP. Protokół ten nie służy w tym przypadku do określania stanu aplikacji, a jedynie do przekazywania żądań i odpowiedzi na jednym URI, np. /getUser, przy użyciu tylko jednej metody HTTP. Jest to klasyczny przykład modelu RPC, którem u o wiele bliżej do SOAP i XML-RPC niż do REST.
Poziom 1. — zasoby N a tym poziomie zaczyna się rozpoznawanie różnych zasobów. Możliwe jest komunikowanie się z różnymi punktam i końcowymi, ponieważ każdy z nich reprezentuje inny zasób. Wykorzystuje się URI w rodzaju POST resou rces/123, ale nadal używa się tylko jednej metody HTTP.
Poziom 2. — czasowniki HTTP N a tym poziomie w pełni wykorzystuje się czasowniki HTTP i używa się ich w połączeniu z rzeczownikami oznaczającymi zasoby. Jest to rodzaj usług REST-owych, jaki został opisany we wcześniejszej części tego rozdziału. Programista wykorzystuje cały potencjał protokołu HTTP. Ale to nadal nie jest najwyższy poziom zgodności z REST.
Poziom 3. — kontrolki hipermedialne Na tym poziomie model wykorzystuje HATEOAS (ang. Hypermedia as the Engine o f Application State) do przekazywania stanu aplikacji. Celem kontrolek hiperm edialnych jest podsunięcie klientowi kolejnych kroków do wykonania oraz dostarczenie potrzebnych do tego celu adresów URI. Sposoby implementacji i działania stopnia HATEOAS opisaliśmy w dalszej części rozdziału.
Projektowanie REST-owego interfejsu API Dobrze zaprojektowany REST-owy interfejs API powinien być jednolity. Aby zdefiniować interfejs spełniający ten warunek, trzeba dobrze znać m etody protokołu HTTP i kody odpowiedzi serwera oraz mieć kompleksową wiedzę w zakresie struktury danych swojej aplikacji. Celem jest stworzenie prostych, przejrzystych i eleganckich identyfikatorów URI zasobów. 4 Przystępny opis m o d elu dojrzałości R ichardsona zam ieścił w sw oim serwisie M a rtin Fowler; m artinfow ler.com /articles/richardsonM aturityM odel.htm l.
186
| ROZDZIAŁ 13. REST-owe usługi sieciowe
OPOWIADANIE WOJENNE Wjednej z firm, w których pracowałem, panował zwyczaj, że zespół, który ukończyłjakiś projekt, przedstawiał wynik swojej pracy pozostałym zespołom. Były to czasy, kiedy technologia REST nabierała rozpędu. Jedna z drużyn postanowiła zbudować REST-owy system zaplecza do obsługi klientów mobilnych i internetowych. Z zachwytem słuchaliśmy, jak stworzyli elegancki system, który bezproblemowo serwował dane dla obu rodzajów klientów. Ale gdy szef zespołu przeszedł do omawiania technicznych aspektów rozwiązania, odkryliśmy, że aplikacja przechowywała stan klienta na serwerze. Jest to sprzeczne z zasadami REST. Podniosłem tę kwestię i spytałem, czy program aby na pewno był w pełni REST-owy. Oczywiście architekt dał do zrozumienia, że poczuł się urażony, ale przeszedł do opisu dokumentacji interfejsu i wyjaśniania sposobów współpracy klientów z OAuth oraz przekazywania parametrów w adresach URL. Jednak działanie systemu opierało się na przechowywaniu stanu, a nie jego przekazywaniu. Programiści i projektanci systemów lubią nowinki i chcą być modni. Ale jeśli ktoś nie zrozumie podstawowych zasad używanej technologii i nie przeanalizuje możliwości jej zastosowania w danym przypadku, to zamiast zabłysnąć, wyjdzie na dziwaka, któremu nie udało się zrobić wrażenia na innych, choć bardzo się starał. W opisanym przypadku panowie zbudowali aplikację typu „przechowywanie stanu reprezentacyjnego", a nie „przekazywanie stanu reprezentacyjnego". W krótce dowiesz się, jakie elementy składają się na URI.
Nazewnictwo zasobów REST-owe interfejsy API pisze się dla klientów, więc powinny być dla nich zrozumiałe. Aby wybrać odpowiednie rzeczowniki dla nazw zasobów, trzeba znać strukturę danych aplikacji oraz wiedzieć, jak klienci będą z niej korzystać. Nie m a ściśle określonych reguł nazywania zasobów, ale jest kilka konwencji, których przestrzeganie pozwala utworzyć zrozumiałe nazwy.
Rzeczowniki, a nie czasowniki Nazwy zasobów powinny być rzeczownikowe, nie czasownikowe, ponieważ nazwa m a stanowić reprezentację zasobu. Natom iast czynności do wykonania określają czasowniki HTTP. Nieco dalej znajduje się szczegółowy opis m etod HTTP. Do reprezentacji pojedynczego zasobu użytkownika pow inno się użyć nazwy us e r s reprezentującej wszystkich użytkowników oraz identyfikatora jednego konkretnego użytkownika, np. users/123456. Natomiast URI users/123456/update jest nieprawidłowy albo przynajmniej niezgodny z zasadami REST, podobnie jak zawierający łańcuch zapytania identyfikator URI users/123456?action=update. Dane są z natury hierarchiczne. W yobraź sobie, że chcesz utworzyć reprezentację wszystkich wpisów użytkownika o identyfikatorze 123456. Rozwiązanie jest proste: należy użyć rzeczownika posts do reprezentacji wszystkich wpisów i utworzyć identyfikator URI users/123456/ posts. Wcześniej napisaliśmy, że reprezentacja zasobu nie jest samym zasobem, tylko właśnie jego reprezentacją, więc jeden zasób m ożna reprezentować na wiele sposobów. Do reprezentowania wszystkich wpisów wybranego użytkownika m ożna użyć identyfikatora URI posts/users/123456. Mając reprezentację zasobu, m ożna coś z nim zrobić za pom ocą jednej z czterech m etod HTTP. Do pobierania zasobów używa się metody GET, a do tworzenia — POST. Jeszcze wrócimy do tego tematu.
Projektowanie REST-owego interfejsu API
187
Znaczenie nazw Jak pokazaliśmy, rzeczowniki powinny odzwierciedlać treść reprezentowanych zasobów. Połączenie ich z identyfikatorami sprawia, że identyfikatory URI są łatwe do rozszyfrowania i zrozumienia. Jeśli nie wystarczy przeczytanie URI i m etod HTTP, aby zorientować się, co reprezentuje dany zasób, oznacza to, że ten identyfikator nie spełnia wymogów REST.
Liczba mnoga Nazwy zasobów powinny mieć formę liczby mnogiej, ponieważ reprezentują zbiory danych. Nazwa u se rs reprezentuje zbiór użytkowników, a nazwa p o sts — zbiór wpisów. Idea jest taka, że rzeczownik reprezentuje jakiś zbiór zasobów w usłudze, a identyfikator — pojedynczy egzemplarz z tego zbioru. Oczywiście jeśli jest tylko jeden egzemplarz jakiegoś zasobu, to do jego reprezentacji można użyć rzeczownika w liczbie pojedynczej, ale to raczej rzadkość.
Metody HTTP W specyfikacji protokołu HTTP 1.1 zdefiniowano osiem m etod HTTP, ale tylko cztery z nich są powszechnie wykorzystywane przy projektowaniu REST-owych interfejsów API — GET, POST, PUT i DELETE. Każda z nich m a określone zadanie w kontekście REST. Szczególnie ważne w odniesieniu do nich jest pojęcie idem potencji. W przypadku API REST-owych idempotencja to taka cecha, że każde odwołanie przez klienta do określonego identyfikatora URI zawsze daje taki sam wynik. Innymi słowy: niezależnie czy klient wyśle do serwera żądanie raz, czy wiele razy, skutek tego zawsze będzie taki sam. (Oczywiście przy założeniu, że w tym czasie coś innego nie zmieniło stanu zasobu). Z czterech powszechnie wykorzystywanych m etod cechę idempotencji m a tylko m etoda GET. Oznacza to, że żądania GET do określonego URI nie mogą powodować żadnych zmian na serwerze. M etodą tą nie m ożna tworzyć, aktualizować ani usuwać zasobów. W specyfikacji HTTP 1.1 m etodę tę opisano jako bezpieczną, ponieważ „pow inna służyć tylko do pobierania inform acji”. W kontekście REST m etoda ta służy do pobierania reprezentacji zasobów z serwera. Nie można przy jej użyciu zmieniać danych. Pozostałe trzy metody — POST, PUT i DELETE — nie są idempotentne, więc mogą powodować zmiany na serwerze. Sposób ich użycia przedstawimy na przykładzie forum internetowego. Ponadto dowiesz się, jakie kody odpowiedzi HTTP (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) m oże zwracać serwer oraz z czego składają się takie odpowiedzi.
GET Metoda ta służy do pobierania reprezentacji zasobu z usługi. Nie należy jej używać do aktualizowania, usuwania ani tworzenia zasobów. Jednokrotne jej wykonanie powinno dawać taki sam skutek jak wykonanie wielokrotne. Jeśli żądany zasób zostanie znaleziony, następuje jego zwrot w odpowiedzi HTTP w żądanym formacie, którym często jest JSON lub XML. Kod zwrotny HTTP to w takim przypadku 200 OK. Jeśli zasób nie zostanie znaleziony, usługa powinna zwrócić kod 404 Not found, a jeżeli żądanie jest nieprawidłowo skonstruowane, odpowiednim kodem błędu jest 400 Bad request. Przykładem prawidłowego URI, którego można użyć w aplikacji forum, jest GET use rs/123456/followe rs — reprezentuje wszystkich użytkowników obserwujących użytkownika 123456.
188
| ROZDZIAŁ 13. REST-owe usługi sieciowe
POST M etoda POST służy do tworzenia nowych zasobów w określonym kontekście. Aby np. utworzyć nowego użytkownika, należy wysłać tą m etodą do zasobu users żądanie z potrzebnymi danymi. Usługa utworzy nowy zasób, powiąże go z kontekstem i przypisze m u identyfikator. Jeśli operacja się powiedzie, aplikacja pow inna zwrócić kod HTTP 201 Created i odnośnik do nowo utworzonego zasobu w nagłówku Location odpowiedzi lub w treści w formacie JSON. W treści odpowiedzi może zostać przesłana cała reprezentacja zasobu. Często robi się tak po to, by uniknąć dodatkowego wywołania API w celu pobrania reprezentacji właśnie utworzonych danych. W ten sposób zmniejsza się liczbę cykli żądanie-odpowiedź w API. Oprócz kodów odpowiedzi opisanych przy metodzie GET m etoda POST może zwracać kod 204 No content, jeżeli treść żądania jest pusta. Przykładem prawidłowego URI w aplikacji forum może być POST users z danymi nowego użytkownika w treści albo POST users/ 123456/posts, jeśli trzeba utworzyć nowy wpis dla użytkownika 123456 z danych przesłanych w treści żądania.
PUT M etoda PUT jest najczęściej używana do aktualizowania znanych zasobów. Identyfikator URI pow inien zawierać inform acje pozwalające zidentyfikować zasób, np. kontekst i identyfikator. Treść żądania pow inna zawierać zaktualizowaną wersję zasobu i jeśli operacja się powiedzie, aplikacja powinna zwrócić kod odpowiedzi HTTP 200. Przykładowy URI aktualizujący informacje użytkownika to PUT users/123456. Rzadziej m etody PUT używa się do utworzenia zasobu, jeżeli klient utworzy identyfikator tego zasobu. Jednak ten sposób tworzenia zasobów jest mylący. Po co używać m etody PUT, skoro do tego samego służy metoda POST, która jest dobrze wszystkim znana? W kwestii aktualizacji zasobów należy odnotować, że w żądaniu HTTP do usługi wysyłana jest cała reprezentacja zasobu, a nie tylko te informacje, które są zmieniane.
DELETE Metoda ta służy do usuwania zasobów. Identyfikator URI powinien zawierać kontekst i identyfikator zasobu. Aby usunąć użytkownika o identyfikatorze 123456, należy użyć URI DELETE users/123456. W odpowiedzi może zostać przesłana reprezentacja usuniętego zasobu. Powodzenie operacji oznacza kod odpowiedzi HTTP 200 OK. Jeśli zasób nie zostanie znaleziony, następuje zwrot kodu 400.
REST w akcji Zaprojektujemy REST-owy interfejs API dla forum przy użyciu wiadomości zdobytych w pierwszej części tego rozdziału. Najpierw przeanalizujemy strukturę danych serwisu i zidentyfikujemy dziedziny danych. Dwie najważniejsze dziedziny to użytkownicy i wpisy. W śród użytkowników m ożna jeszcze wyróżnić tych, którzy kogoś obserwują, a wpisy najczęściej organizuje się tematycznie. Na podstawie tych dziedzin możemy wymyślić identyfikatory URI do reprezentowania zasobów.
Rzeczownik users W iadomo, że aby utworzyć nowego użytkownika, należy użyć m etody POST i kontekstu users. W związku z tym identyfikator URI tworzący nowego użytkownika powinien wyglądać tak: POST /users
REST w akcji
| 189
Wszystkie informacje potrzebne do utworzenia użytkownika powinny znajdować się w treści żądania. W odpowiedzi powinien znajdować się URI reprezentacji użytkownika, którego można użyć w żądaniu GET, np. GET / users/123456. Żądanie to pobiera informacje o użytkowniku legitymującym się identyfikatorem 123456. Jeżeli trzeba zaktualizować użytkownika, należy użyć m etody PUT, np. PUT / users/123456. Aby usunąć użytkownika, należy skorzystać z m etody DELETE, np. DELETE users/123456. Jeśli trzeba usunąć kilku użytkowników, to m ożna wysłać żądanie do DELETE /us er s zawierające identyfikatory wszystkich tych użytkowników w treści. W ten sposób wykona się o wiele mniej żądań, niż gdyby każdego użytkownika usuwano w osobnym żądaniu. Aby pobrać wszystkich użytkowników z usługi, można użyć żądania GET / u s e r s . Takie wywołanie oczywiście podlega zabezpieczeniom, tak że listę użytkowników mógłby pobrać tylko ktoś, kto ma odpowiednie uprawnienia. To wszystko, jeśli chodzi o kontekst użytkowników. Teraz przyjrzymy się bliżej kwestii obserw atorów . Obserwator to taki użytkownik, który obserwuje innego użytkownika, ponieważ interesują go jego wpisy. Aby pobrać listę wszystkich użytkowników obserwujących wybranego użytkownika, można użyć m etody GET w następujący sposób: GET /users/123456/followers Aby utworzyć nowego obserwatora użytkownika, należy przekazać identyfikator tego obserwatora w treści żądania POST / us er s/ 12 3 4 56 /f ol l o w e rs . Informacje o obserwatorze m ożna pobrać na dwa sposoby: GET /users/123456/followers/456789 lub GET /users/456789 Są to dwa przykłady reprezentacji jednego zasobu. Aby usunąć obserwatora danego użytkownika, można użyć następującego żądania: DELETE /users/123456/followers/456789 Spowoduje to usunięcie użytkownika 456789 z listy obserwatorów użytkownika 123456, ale nie jego całkowite skasowanie z systemu. Aby bezpowrotnie usunąć użytkownika, należy użyć następującego żądania: DELETE /users/456789 Takie są właściwości kontekstu obserwatorów. Teraz przyjrzymy się tem atom i wpisom.
Rzeczowniki topics i posts Wiesz już, jak utworzyć użytkownika za pom ocą metody POST. Podobnie tworzy się tem aty (ang. topic) i wpisy (ang. post). Aby utworzyć temat, należy użyć następującego żądania: POST /topics Aby utworzyć wpis pod tematem, należy użyć następującego żądania: POST /topics/123/posts
190
| ROZDZIAŁ 13. REST-owe usługi sieciowe
Nie m ożna utworzyć wpisu w taki sposób: POST /posts Problemem jest brak kontekstu. Usługa nie m a wystarczających informacji, aby utworzyć wpis, ponieważ nie wie, do którego tem atu wpis ten powinien być przyporządkowany. Aby pobrać tem at i wpis, należy użyć następującego żądania: GET /topics/123 Aby pobrać wybrany wpis spod tem atu, należy użyć żądania: GET /topics/123/posts/456 lub GET /posts/456 Aby skasować tem at lub wpis, należy użyć następującego żądania: DELETE /topics/123 Aby skasować wpis, należy użyć żądania: DELETE /topics/123/posts/456 lub DELETE /posts/456 Aby zmienić wpis lub temat, m ożna użyć jednej z trzech poniższych metod: PUT /topics/123 PUT /topics/123/posts/456 PUT posts/456 Po zdefiniowaniu najprostszych identyfikatorów URI i kontekstów m ożna zacząć tworzyć bardziej skomplikowane kombinacje użytkowników, tematów i wpisów. Aby pobrać reprezentację wszystkich tematów opublikowanych przez określonego użytkownika, należy użyć następującego żądania: GET /users/123456/posts Aby pobrać wszystkie wpisy użytkownika pod wybranym tematem, należy użyć następującego żądania: GET /users/123456/topics/123/posts Aby pobrać wszystkie wpisy obserwatora danego użytkownika w wybranym temacie, należy użyć poniższego żądania: GET /users/123456/followers/456789/topics/123/posts Przy tworzeniu kom binacji zasobów możesz puścić wodze fantazji, ale nie zapominaj, że identyfikatory URI REST-owego interfejsu API są używane przez klientów i muszą być dla nich zrozumiałe. Dlatego zawsze należy dążyć do maksymalnej prostoty. Jeśli stworzysz tak skomplikowany URI, który wymaga objaśnienia, to możliwe, że trzeba go będzie przebudować. Przykładem dobrze zaprojektowanego REST-owego interfejsu API jest usługa chmurowa firmy Sugarsync (https://www.sugarsync.com/developer). W arto przyjrzeć się ich rozwiązaniom, aby zobaczyć, jak zdefiniowali zasoby folderowe, adresowe i przestrzeni roboczej. Zwróć uwagę na sposoby tworzenia, odczytywania i usuwania zasobów przy użyciu m etod HTTP.
Implementacja REST w Javie EE
I
191
Implementacja REST w Javie EE W poprzedniej części rozdziału szczegółowo opisaliśmy teoretyczne podstawy projektowania REST-owych interfejsów API. Skoro wiesz już, jak pow inny wyglądać identyfikatory URI, m ożem y przejść do im plem entacji ich obsługi. Java EE 7 zapewnia kilka adnotacji, które ułatwiają tworzenie REST-owych API. Najbardziej przydatna z nich to adnotacja @Path. Definiuje ona kontekstowy identyfikator URI i klasę lub metodę służącą do przetwarzania żądań do tego identyfikatora. Ponadto dostępne są adnotacje dla wszystkich m etod HTTP: @GET, @POST, @PUT, @DELETE itd. Przy ich użyciu oznacza się metody służące do przetwarzania żądań wysyłanych poszczególnymi metodam i HTTP. W aplikacji może być wiele kontekstów REST-owych. Dlatego dostarczono adnotację @ A pplicationPath, której param etr określa przestrzeń dla API. Te dwa typy adnotacji wystarczą do zaimplementowania prostego REST-owego interfejsu API. N a listingu 13.1 znajduje się implementacja URI GET /u s e rs . Listing 13.1. Najprostsza implementacja REST-owego interfejsu API w Javie EE package co.uk.devchronicles.forum ; import import import import
javax.w s.rs.A pplicationP ath; javax.ws.rs.GET; jav ax .w s.rs.P ath ; jav ax .w s.rs.co re.A p p licatio n ;
@ ApplicationPath("/") @Path("users") public c la ss Users extends A pplication! @GET public S tring getU sers(){ return "Tu powinna znajdować s ię reprezentacja wszystkich użytkowników."; } } Jeśli wdrożysz tę aplikację w swoim komputerze i nazwiesz ją forum, to możesz przetestować ten URI, wpisując w przeglądarce adres: http://localhost/forum/users. Powinien pojawić się napis: Tu powinna znajdować s ię re p re z e n ta c ja w szy stkich użytkowników. Zwróć uwagę na zastosowanie adnotacji @Path do klasy i przekazanie jej kontekstu users. Przekazywany łańcuch nie musi mieć z żadnej strony ukośnika. Przestrzeń, w którym będzie istniał interfejs REST-owy, została zdefiniowana jako korzeń (" /" ) aplikacji. Metoda, która m a być wywoływana w odpowiedzi na żądania GET do URI u sers, jest oznaczona adnotacją @GET. W tym prostym przykładzie zwracany jest łańcuch, ale oczywiście w prawdziwej aplikacji byłyby to pobrane z bazy danych informacje w formacie JSON lub XML wraz z kodem statusu HTTP. Pokazano to na listingu 13.2. Listing 13.2. Wysłanie klientowi odpowiedzi z treścią w formacie JSON package co.uk.devchronicles.forum ; import ja v a .u til.A rra y L is t; import jav ax .jso n .Jso n ;
192
I
import import import import import import import import
ROZDZIAŁ 13. REST-owe usługi sieciowe
javax.json.JsonArrayBuilder; javax.ws.rs.ApplicationPath; javax.ws.rs.GET; javax.ws.rs.Path; javax.ws.rs.Produces; javax.ws.rs.core.Application; javax.ws.rs.core.MediaType ; javax.ws.rs.core.Response;
@ApplicationPath( "/") @Path("users") public class Users extends Application{ @GET @Produces(MediaType.APPLICATION_JSON) public Response getUsers(){ ArrayList allUsers = this.findAllUsers(); JsonArrayBuilder jsonArrayBuilder = Json.createArrayBuilder(); for(User user : allUsers){ j sonArrayBuilder.add( Json.createObj ectBuilder() .add("id", user.getId()) .add("firstname", user.getFirstname()) .add("lastname", user.getLastname()) ); } return Response.ok(jsonArrayBuilder.build() ) . build(); } public ArrayList findAllUsers(){ ArrayList allUsers = new ArrayList<>(); allUsers.add(new User(123456, "Alex","Theedom")); allUsers.add(new User(456789, "Murat","Yener")); return allUsers; } } Kod ten generuje obiekt JSON z danych użytkownika z bazy danych (dla uproszczenia do zwracania danych użyto metody) i wysyła go do klienta z kodem statusu HTTP 200. Pierwszą rzeczą, która pow inna przykuć Twoją uwagę, jest to, że m etoda getUsers() m a adnotację @Produces(MediaType.APPLICATION_JSON) ;. Określa ona typ MIME zwracany przez tę metodę do klienta. Do utworzenia danych w formacie JSON użyto klas javax .j son.Json i javax .j son . ^JsonArrayBuilder. Następnie, przed zwróceniem ich do klienta, opakowano je w obiekt typu javax.ws .rs.core.Response. Jeśli wszystko pójdzie dobrze, w przeglądarce powinien pojawić się następujący wynik: [ {"id": 123456,"firstname":"Alex", "lastname":"Theedom"}, {"id":456789,"firstname":"Murat" , "lastname":"Yener"} ] Wiesz już, jak pobrać reprezentację wszystkich użytkowników znajdujących się w systemie. Natom iast nie wiesz, jak pobrać tylko jednego użytkownika za pomocą jego identyfikatora. Jest to równie łatwe. W URI należy przekazać identyfikator jak poniżej: GET /users/123456
Implementacja REST w Javie EE
| 193
W klasie kontrolera REST pobiera się ten identyfikator ze ścieżki REST oraz wykorzystuje się zm ienną URI w celu przekazania tego identyfikatora do metody. M etodę wykorzystującą wywołanie API oznacza się adnotacją @Path("/{id}") i w sygnaturze tej m etody dodatkowo oznacza się adnotacją argum ent, do którego m a zostać przekazany identyfikator. @GET @Path("/{id}") @Produces(MediaType.APPLICATION_JSON) public Response getUser(@PathParam("id") String id){ User user = this.findUser(id); JsonArrayBuilder jsonArrayBuilder = Json.createArrayBuilder(); j sonArrayBuilder.add( Json.createObjectBuilder() .add("id", user.getId()) .add("firstname", user.getFirstname()) .add("lastname", user.getLastname()) ); return Response.ok(j sonArrayBuilder. build( ) ) . build(); } public User findUser(String id){ return new User("123456", "Alex","Theedom"); } Jak widać w przedstawionym przykładzie, param etr łańcuchowy identyfikatora jest oznaczony adnotacją @PathParam("id"), a więc identyfikator pobrany z URI przez adnotację @Path ("/{id}") zostanie przekazany do tej metody. Do adnotacji @Path nie trzeba wstawiać pełnej ścieżki URI, ponieważ w adnotacji klasowej @Path ustawiony jest bazowy URI. Wszystkie ścieżki ustawione w metodach odnoszą się do tej ścieżki bazowej. Zmienna URI może być wyrażeniem regularnym. Na przykład adnotacja @Path ("/{id: [0-9]*}") odnosi się tylko do identyfikatorów będących liczbami. Jeśli zostanie użyty identyfikator niepasujący do tego wzorca, do klienta zostanie zwrócona odpowiedź HTTP 404. Na razie przedstawiliśmy kilka konstrukcji URI składających się z jednego rzeczownika i zmiennej URI. A jak obsłużyć bardziej skomplikowane URI, takie jak np. GET /users/123456/followers/456789? Robi się to tak samo jak wcześniej, tylko komplikuje się nieco zawartość adnotacji @Path i @PathPa ram. @GET @Path("/{user_id}/followers/{follower_id}") @Produces(MediaType.APPLICATION_JSON) public Response getUser( @PathParam("user_id") String user_id, @PathParam("follower_id") String follower_id) Sposoby użycia m etody HTTP GET są Ci już dobrze znane, ale nie pokazaliśmy jeszcze żadnych przykładów obsługi m etod POST, PUT i DELETE. Implementacja metody reagującej na żądania typu POST jest podobna do m etody obsługującej żądania GET, ale różni się od niej dwoma elementami. Zamiast adnotacji @GET dodaje się adnotację @POST, a zamiast @Consumes stosuje się @Produces. Oto prosty przykład: @POST @Consumes(MediaType.APPLICATION_JSON) @Path("/{user_id}/followers/") public Response createUser(@PathParam("user_id") String user_id, String body)
194
I
ROZDZIAŁ 13. REST-owe usługi sieciowe
Przykład ten działa tak samo jak obsługa metody GET, ale zwróć uwagę na brak jawnego mapowania treści żądania HTTP na param etr metody. Mapowanie to jest teraz niejawne. Treść żądania HTTP jest przekazywana do jedynego param etru bez adnotacji znalezionego w sygnaturze metody. Aby uniknąć nieporozum ień, sygnatura m etody może zawierać tylko jeden taki parametr. M etody HTTP PUT i DELETE obsługuje się w podobny sposób jak metodę POST. Identyfikator URI może zawierać param etry zapytania. M ożna je pobierać przez dodanie do param etru w sygnaturze m etody adnotacji, np. @QueryPa ram ("page"). Adnotacja ta pobiera param etr zapytania page z URI /users?page=10. W API JAX-RS jest wiele innych adnotacji ułatwiających projektowanie REST-owych interfejsów API. W arto poznać je wszystkie.
HATEOAS Jak już napisaliśmy, HATEOAS to najwyższy poziom implementacji technologii REST w modelu dojrzałości Richardsona, czyli coś w rodzaju nirwany REST-owości. W yobraź sobie, że klient żąda zasobu reprezentującego wszystkie znajdujące się w systemie wpisy, które klient ten ma prawo oglądać. Identyfikatorem URI takiego żądania byłby GET /p o s ts , a odpowiedź HTTP zawierałaby następującą treść: { "posts": [ { "id": 71892, " t i t l e " : "Najlepszy film 2015 roku", "content": "Moim zdaniem najlepszym filmem 2015 roku je s t Złote ja jo z Siam.", " lin k s " : [ { "re l" : " s e lf" , "href": "h ttp ://lo c a lh o s t:8 0 8 0 /re s t/p o s ts /7 1 8 9 2 " , "method": "GET" "re l" : "re p lie s " , "href": "h ttp ://lo c a lh o s t:8 0 8 0 /re s t/p o sts/7 1 8 9 2 /p o sts" , "method": "GET" "re l" : "follow er", "href": "h ttp ://lo c a lh o st:8 0 8 0 /re s t/p o sts/7 1 8 9 2 /fo llo w e rs", "method": "GET" "re l" : "owner", "href": "h ttp ://lo c a lh o st:8 0 8 0 /re s t/p o sts/7 1 8 9 2 /u se rs" , "method": "GET" }
] },
HATEOAS
| 195
{ "id": 71893, " t i t l e " : "Najgorszy film 2015 roku", "content": "Najgorszy film to na pewno Być sobą.", " lin k s " : [ { "re l" : " s e lf" , "href": "h ttp ://lo c a lh o s t:8 0 8 0 /re s t/p o s ts /7 1 8 9 3 " , "method": "GET" }, { "re l" : "owner", "href": "h ttp ://lo c a lh o st:8 0 8 0 /re s t/p o sts/7 1 8 9 3 /u se rs" , "method": "GET" } ] } ] } W powyższym kodzie znajduje się sporo ciekawych rzeczy. Odpowiedź HTTP jest w postaci pojedynczego obiektu w formacie JSON o nazwie po st, który zawiera tablicę wpisów: { "posts": [ { . . . pierwszy element ta b lic y }, { . . . drugi element ta b lic y } ] } W przykładowej tablicy znajdują się tylko dwa elementy reprezentujące wpisy. Każdy wpis jest obiektem JSON o następującym formacie: { "id": 71892, " t i t l e " : "Najlepszy film 2015 roku", "content": "Moim zdaniem najlepszym filmem 2015 roku je s t Złote ja jo z Siam.", } Jak widać w przytoczonym przykładzie, kod JSON zawiera identyfikator, tytuł i treść wpisu. Jest to najmniejszy dopuszczalny zbiór informacji, jaki chcielibyśmy otrzymać dla żądania zasobu wpisu niezależnie od poziom u dojrzałości interfejsu REST. Omawianą odpowiedź wyróżnia jednak obecność elementu lin k s . "lin k s": [ { "re l" : " s e lf" , "href": "h ttp ://lo c a lh o s t:8 0 8 0 /re st/p o s ts /7 1 8 9 2 " , "method": "GET" }, ]
196
I
ROZDZIAŁ 13. REST-owe usługi sieciowe
Jest to właśnie przykład zastosowania zasady HATEOAS. Definicja każdego odnośnika w tej tablicy składa się z trzech części. Element r e l oznacza relację łącza h re f w stosunku do bieżącego zasobu, element h re f to odnośnik do większej ilości zasobów, a method to metoda, przy użyciu której należy pobierać zasób. Element r e l może mieć dowolną wartość, która nie musi być zgodna z jakąkolwiek konwencją, chociaż zazwyczaj s e lf oznacza, że łącze reprezentuje dodatkowe informacje o bieżącym zasobie. W tym przypadku odnosi się po prostu do siebie. Pozostałe odnośniki odnoszą się do odpowiedzi na wpis napisanych przez innych użytkowników, użytkowników śledzących wpis (obserwatorów) oraz użytkownika, który jest autorem wpisu. W tablicy łączy może znaleźć się reprezentacja każdego zasobu mającego związek z danym wpisem. Jak widać w przedstawionym przykładzie, w tablicy odnośników pierwszego wpisu z tablicy znajdują się cztery elementy, a drugiego — tylko dwa. Jest to spowodowane tym, że drugi wpis nie jest przez nikogo śledzony i nikt na niego nie odpowiedział. Dostarczone w ten sposób łącza dają klientowi informacje potrzebne do znalezienia dalszych zasobów i ułatwiają rozszerzanie API. Przykładem dobrze zaprojektowanej implementacji HATEOAS jest interfejs API serwisu PayPal (https://developer.paypal.com/docs/integration/direct/paypal-rest-payment-hateoas-links/). W ykorzystano w nim HATEOAS w celu um ożliwienia program istom budowy API współpracujących z systemem płatności przy użyciu łączy dostarczonych w tablicy łączy.
Gdzie i kiedy używać REST REST to łatwy, prosty i ugruntowany zestaw technik, które nie są ograniczone żadnymi standardami. Ktoś może stwierdzić, że to wada, a nie zaleta w porównaniu z protokołem SOAP, który jest znanym standardem o ściśle zdefiniowanych zasadach implementacji. Jednak łatwość implementacji REST przeważa nad problem am i stwarzanymi przez brak standardu. Utworzenie zasobu REST-owego do użytku przez klientów sprowadza się do zdefiniowania odpowiedniego identyfikatora URI i wykorzystania m etod HTTP. Protokół HTTP jest językiem internetu, który znają wszyscy. Dla implementacji REST ograniczenia przepustowości nie stanowią wielkiego problemu, dzięki czemu technologia ta jest szczególnie atrakcyjna dla użytkowników urządzeń mobilnych. Wysłanie żądania zasobu przy użyciu REST-owego interfejsu API niewiele kosztuje, ponieważ jest to zwykłe żądanie HTTP, dla którego może zostać zwrócona odpowiedź w dowolnym formacie. Nie musi to być koniecznie JSON ani XML. Równie dobrze aplikacja może zwracać dane w formacie ATOM lub dowolnym innym. Reprezentacja zasobów przy użyciu prostych identyfikatorów URI zapewnia elastyczność pozwalającą program istom klientów na puszczenie wodzy fantazji. Przy użyciu Ajaksa m ożna wywoływać jeden lub więcej URI, np. u kilku różnych dostawców interfejsów typu REST. Potem wszystkie otrzymane odpowiedzi można połączyć i w ten sposób zapewnić bogatą treść użytkownikom. Jeśli w swojej implementacji REST wykorzystujesz protokół HTTP (co jest bardzo prawdopodobne), to w promocji dostajesz możliwość buforowania zasobów. Buforowanie jest ważną funkcją tego protokołu, z której m ożna korzystać przez odpowiednie ustawienie wartości nagłówków HTTP.
Podsumowanie
| 197
Podsumowanie Interfejs API zgodny z zasadami REST powinien być prosty i intuicyjny w obsłudze dla innych programistów. Naszym zadaniem jako twórców interfejsu jest zaprojektowanie takiego API, które spełnia wymogi aplikacji i jednocześnie zapewnia użytkownikom dostęp do zasobów. W tym rozdziale opisaliśmy tylko najważniejsze zagadnienia dotyczące prawidłowego projektowania REST-owych interfejsów API. O wielu ważnych kwestiach nie wspomnieliśmy. Zaliczają się do nich np.: bezpieczeństwo, sposoby użycia łańcuchów zapytania oraz wykonywanie zadań na serwerze. Na szczęście interfejsy typu REST są powszechnie spotykane i można przejrzeć wiele źródeł informacji, jak zaimplementować prawdziwy REST-owy interfejs API. Wystarczy poszperać trochę w internecie, aby znaleźć mnóstwo artykułów, wpisów na forach i książek poświęconych temu tematowi.
ĆWICZENIA 1.
Poszukaj w internecie publicznych REST-owych interfejsów API i napisz prosty program wykorzystujący ich usługi.
2.
Zaimplementuj URI dla forum opisanego w tym rozdziale i napisz używającego ich klienta.
3.
Stwórz jedną wycieczkę przez serwis przy użyciu kompletnej techniki w stylu HATEOAS.
198 I ROZDZIAŁ 13. REST-owe usługi sieciowe
14 Wzorzec Model - Widok - Kontroler
ZAWARTOŚĆ ROZDZIAŁU:_______ > w p ro w a d z e n ie d o w zo rc a M VC; > p o c h o d z e n ie w zo rca M VC; > im p le m e n ta cja w zo rca M VC p rzy u ży ciu w zo rc ó w zło żo n y c h ; > im p le m e n ta cja w zo rca M VC w Ja v ie EE; > k ie d y i g d z ie u ży w a ć w zo rc a M VC.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r14, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału.
W zorzec M odel - W idok - K o n tro ler (ang. model-view-controller — MVC) to jeden z najpowszechniej stosowanych wzorców projektowych w nowoczesnych aplikacjach, którego opis m ożna znaleźć w książce Bandy Czworga. Jego podstawę stanowi idea rozdziału spraw i oddzielenia części aplikacji przetwarzającej dane od części służącej do ich prezentowania. Brak takiego rozdziału powoduje, że składniki systemu są ze sobą ściśle powiązane, co utrudnia obsługę konserwacyjną i rozszerzanie program u. Rozdział spraw opisywany przez wzorzec MVC ułatwia wprowadzanie zm ian zarówno w logice biznesowej, jak i w interfejsie użytkownika program u. Wzorzec MVC m ożna porównać z wykupieniem usługi telewizji kablowej u jednego dostawcy i zakupem telewizora w sklepie z elektroniką. Pierwszy dostarcza treść, a drugi dba o to, byśmy ją widzieli w odpowiedni sposób. Żaden z nich nie przejmuje się zmianami zachodzącymi
200
| ROZDZIAŁ 14. Wzorzec Model - Widok - Kontroler
w technologiach wykorzystywanych przez drugiego. Klient zawsze może kupić nowy telewizor, gdy pojawią się modele z lepszą matrycą, albo zamówić większą liczbę kanałów i nie musi w tym celu zmieniać odbiornika. Wzorzec MVC jest powszechnie wykorzystywany przez program istów aplikacji sieciowych, dlatego opisujemy go właśnie w tym kontekście.
Czym jest wzorzec MVC W nazwie Model - W idok - Kontroler słowo model reprezentuje dane aplikacji i związaną z nimi logikę biznesową. Model może składać się z jednego obiektu lub być skomplikowaną siatką wielu obiektów. W aplikacji Java EE dane znajdują się w obiektach dziedzinowych, które często są wdrożone w module EJB. Dane przez warstwę dostępu do bazy danych są przekazywane w obiektach DTO (ang. data transfer object), a pobierane przez obiekty DAO (ang. data access object) — więcej informacji na tem at tych obiektów znajduje się w rozdziale 12., „Wzorzec Dostęp do Danych”. W idok to wizualna reprezentacja danych znajdujących się w modelu. Jeden widok reprezentuje pewien podzbiór modelu, a więc pełni funkcję filtru znajdujących się w nim danych. Użytkownik wykorzystuje dane modelu za pośrednictwem wizualnej reprezentacji dostarczanej przez widok i wywołuje logikę biznesową, która działa na danych modelu. K ontroler łączy widok z modelem i kieruje działaniem aplikacji. Wybiera widok do wyrenderowania w odpowiedzi na działania użytkownika i na podstawie przetwarzanej logiki biznesowej. Kontroler odbiera od widoku wiadomość, którą przekazuje do modelu. Model przygotowuje odpowiedź i wysyła ją z powrotem do kontrolera, w którym widok zostaje wybrany i wysłany do użytkownika. Wzorzec MVC obejmuje warstwy klienta i logiki biznesowej architektury wielowarstwowej. W środowisku Javy EE w części biznesowej znajduje się model, który zwykle m a postać modułu EJB. Kontroler i widok znajdują się w warstwie sieciowej. W idok często jest konstruowany przy użyciu JSF lub JSP z pomocą języka EL. Kontroler to z reguły serwlet odbierający żądania HTTP od użytkownika. Dokładniejszy opis architektury wielowarstwowej znajduje się w rozdziale 2., „Podstawy Javy EE”. W zorca MVC często używa się w połączeniu z innymi wzorcami, np.: Polecenie, Strategia, Kompozyt i Obserwator. W tym rozdziale nie opisujemy szczegółowo tych wzorców, ale w przykładzie piszemy nieco o wzorcu Polecenie.
TŁO Pierwsze zmianki o tym wzorcu pojawiły się w czasach przed powstaniem internetu w artykule napisanym przez pracującego w firmie Xerox Parc1 programistę języka Smalltalk Trygvego Reenskauga w grudniu 1979 r. Choć składniki wzorca MVC zostały zdefiniowane ponad 30 lat temu, wciąż są zaskakująco aktualne w dzisiejszych aplikacjach sieciowych. N a rysunku 14.1 przedstawiono proces wysłania przez użytkownika żądania do kontrolera. Kontroler w ram ach obsługi tego żądania aktualizuje model i renderuje nowy widok, który następnie zostaje wysłany do użytkownika. 1 S trona intern eto w a Trygvego M .H . Reenskauga; http://heim .ifi.uio.no/~trygver/them es/m vc/m vc-index.htm l.
Czym jest wzorzec MVC
I 201
Model
Aktualizacja modelu
/
\
Aktualizacja widoku
Wywołanie
widoku
Kontroler
Widok Zadanie użytkownika
Rysunek 14.1. Diagram wzorca Model - Widok - Kontroler
OPOWIADANIE WOJENNE Kiedyś, gdy technologia JSP była na topie, a robak milenijny nie spowodował nuklearnej katastrofy mimo wszelkich zapowiedzi najróżniejszych specjalistów, pracowałem w niewielkiej rozwijającej się firmie. Nasz zespół składał się z kilku programistów Javy i JSP, których wspierało paru specjalistów od Flasha. Planowaliśmy stworzyć portal serwujący dynamiczną treść w zależności od potrzeb klienta, który podpisał z nami umowę. Przystąpiliśmy do pracy z wielkim entuzjazmem i utworzyliśmy dynamiczną stronę internetową, która dla każdego klienta wyświetlała inny zestaw funkcji. Byliśmy bardzo dumni ze swojego produktu, a kupujący go klienci byli zadowoleni z usługi. Odnosiliśmy spory sukces i wszystko toczyło się bardzo szybko. Wszystkim podobały się nasze strony, a my cieszyliśmy się z powodzenia. Jednak szczęście nie trwało długo. Im więcej klientów kupowało nasz produkt, tym trudniej było nad nim zapanować. Naszym błędem było pomieszanie logiki biznesowej z logiką widoku, przez co dla każdego klienta musieliśmy zmieniać cały kod JSP serwisu. Wkrótce kod JSP zamienił się w potworną mieszaninę logiki biznesowej i wizualnej i powstał niestrawny kod spaghetti. Jedynym wyjściem z tego koszmaru było przepisanie całej aplikacji od nowa z zastosowaniem wzorca MVC. Zrobiliśmy tak, jak zaplanowaliśmy, i wszystko zaczęło się układać, ale kosztowało nas to wiele nocy i weekendów w biurze. Morał z tej historii jest taki, że wzorzec MVC nie tylko ułatwia obsługę serwisową aplikacji, ale też pozwala lepiej zapanować nad czasem spędzanym w pracy.
Typy wzorca MVC Jest wiele odm ian wzorca MVC. Najpowszechniej znane nazywa się typami I i II. ^
Typ I w zorca M VC — typ ten reprezentuje podejście, w którym centralną rolę odgrywa strona, a widok i kontroler stanowią jedność zwaną widokiem - kontrolerem. Logika kontrolna jest w tym przypadku zaimplementowana w widoku, jak np. w JSF. Wszystkie czynności wykonywane przez kontroler, wliczając pobieranie atrybutów i param etrów żądań HTTP, wywoływanie logiki biznesowej i obsługę sesji HTTP, są osadzone w widoku przy użyciu skryptletów i bibliotek znaczników. Typ I ściśle wiąże mechanizmy generowania widoku z przepływem sterowania aplikacji, co utrudnia jej obsługę serwisową.
202
I
^
ROZDZIAŁ 14. Wzorzec Model - Widok - Kontroler
Typ II wzorca MVC — problem y dotyczące obsługi serwisowej obecne w typie I wyeliminowano przez oddzielenie logiki kontrolera od widoku i przeniesienie jej do serwletu, dzięki czemu JSF zajmuje się tylko renderowaniem danych dla widoku.
MVP — ALTERNATYWA DLA MVC Akronim MVP oznacza angielskie słowa model, view,presenter (model, widok, prezenter) i jest nazwą wzorca stanowiącego alternatywę dla MVC. Zamiast tworzyć trójstronną relację między kontrolerem, widokiem i modelem, jak jest w przypadku MVC, MVP zapewnia każdej ze stron jeden sposób komunikacji — prezenter obsługuje całą komunikację zachodzącą między widokiem i modelem. Wzorzec ten jest dość popularny wśród użytkowników technologii: .NET, Silverlight, Google Web Toolkit i Vaadin. Najważniejsza różnica między typami I i II wzorca MVC dotyczy umiejscowienia logiki kontrolującej: w typie I jest ona w widoku, a w typie II — w serwlecie. Wiele systemów szkieletowych, takich jak: Spring MVC, Struts, Grails i W icket, m a własne im plem entacje wzorca MVC typu II. Na przykład w Springu MVC zastosowano koncepcję serwletu dyspozytora (ang. dispatcher), który odbiera żądania HTTP i zleca zadania kontrolerowi, widokowi (i algorytmowi do wybierania widoków) oraz procedurom obsługowym. Na rysunku 14.2 przedstawiono schemat implementacji wzorca MVC z systemu Spring.
Algorytm wybierania widoków
Mapowanie obsługi
a
^
"
■B
¡Í
Serwlet dyspozytor i Żądanie HTTP
Odpowiedź HTTP
Rysunek 14.2. Schemat implementacji wzorca MVC w systemie Spring
Implementacja wzorca MVC w zwykłym kodzie Zaimplementujem y wzorzec MVC przy użyciu wzorca Polecenie, który opisuje sposoby określania, w jakie miejsce skierować użytkownika na podstawie żądania, które przesłał. Wzorzec ten pomaga w wykonywaniu jedynej funkcji kontrolera. Pracę zaczniemy od zdefiniowania klasy kontrolera. Na listingu 14.1 znajduje się prosta implementacja odpowiadająca na żądania HTTP GET wysyłane do ścieżki / u s e r s / * . Mapowanie tej relacji jest zdefiniowane w pliku web.xml:
Implementacja wzorca MVC w zwykłym kodzie
| 203
FrontController com.devchronicles.mvc.pl ai n. FrontCont roller FrontController < u rl-p a tte rn > /u se rs/* < /u rl-p a tte rn > W kodzie tym znajduje się odwzorowanie klasy kontrolera com.devchronicles.mvc.plain. ^FrontController na adres URL żądań / u s e r s / * . W efekcie każde żądanie wysłane na ten adres zostanie skierowane do przetworzenia w klasie FrontController.
SERVLETS 3.0 Klasę kontrolera można także opatrzyć adnotacją z adresem URL @ W ebServlet({"/ ^ u s e r s / * " } ) . Dzięki tej adnotacji nie trzeba definiować mapowania serwletu w pliku web.xml. Dla takich żądań wywoływana jest m etoda doGet() i z fabryki A b strac tA ctio n F ac to ry pobrany zostaje obiekt akcji określający lokalizację widoku, który powinien zostać zwrócony do użytkownika. Listing 14.1. Klasa UserService package com.devchronicles.mvc.plain; import import import import import import
java.io.IOException; javax.servlet.ServletException; javax.servlet.annotation.WebServlet; j av ax. s ervl et .http.HttpServlet; j av ax. s ervl et .http.HttpServletRequest; j av ax. s ervl et .http.HttpServletResponse;
public class FrontController extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { Action action = AbstractActionFactory.getInstance().getAction(request); Strin g view = action.execute(request, response); getServletContext().getRequestDispatcher(view).forward(request, response); } } Na listingu 14.2 znajdują się dwie klasy — AbstractActionFactory i ActionFactory. Pierwsza tworzy egzemplarz klasy ActionFactory. M etoda getAction klasy ActionFactory przyjmuje obiekt HttpServletRequest zawierający referencję do URI zażądanej lokalizacji. Fabryka na podstawie URI wybiera obiekt akcji do zwrócenia kontrolerowi. Programista przechowuje mapę ścieżek żądań URI i obiektów akcji w słowniku akcji. Obiekt akcji jest wybierany ze słownika na podstawie ścieżki żądania URI i zwracany do kontrolera.
204
I
ROZDZIAŁ 14. Wzorzec Model - Widok - Kontroler
Listing 14.2. Klasa fabryczna
package com.devchronicles.mvc.plain; public class AbstractActionFactory { private fi nal st at ic ActionFactory instance = new ActionFactory(); public s ta ti c ActionFactory getInstance() { return instance; } } package com.devchronicles.mvc.plain; import java.util.HashMap; import java.util.Map; import j av ax. s ervl et .http.HttpServletRequest; public class ActionFactory { private Map actions = new HashMap<>(); private Action action; public ActionFactory() { actions.put("GET/users", new HomeAction()); actions.put("GET/users/listusers", new ListUsersAction()); } public synchronized Action getAction(HttpServletRequest request) { String path = request.getServletPath() + request.getPathInfo(); String actionKey = request.getMethod() + path; System.out.println(actionKey); action = actions.get(actionKey); i f(acti on == null){ action = actions.get("GET/users"); } return action; } } W obiekcie akcji najważniejsze jest to, że konkretna implementacja dostarcza implementację m etody e x e c u t e( ). M etoda ta wykonuje logikę biznesową potrzebną do wygenerowania strony zażądanej przez użytkownika. W razie potrzeby może pobierać dane z bazy danych, wykonywać obliczenia albo generować plik. N a listingu 14.3 m etoda execute klasy ListUserAction tworzy listę użytkowników, którą dodaje jako atrybut do obiektu żądania. Następnie zwraca lokalizację widoku do wyrenderowania i przedstawienia użytkownikowi. Dane zapisane teraz w obiekcie żądania zostają wykorzystane przez stronę l i s t u s e r . j s p i wyświetlone. W celu uproszczenia obiekt List został zapełniony i zwrócony, ale w prawdziwym programie należałoby użyć ziarna EJB lub innych obiektów danych łączących się z bazą danych.
Implementacja wzorca MVC w zwykłym kodzie
I 205
Listing 14.3. Klasa akcji
package com .devchronicles.m vc.plain; import import import import
ja v a .u til.A rra y L is t; j a v a .u t i l .L i s t ; ja v a x .s e r v le t.h ttp .H ttp S erv letR eq u est; ja v a x .s e r v le t.http.H ttpS ervletR esponse;
public c la ss ListUsersAction implements Action { public S tring execute(H ttpServletRequest re q u e st, HttpServletResponse response) { List u serL ist = new ArrayList<>(); userL ist.add("John Lennon"); u s e rL ist.a d d ("Ringo S ta rr" ); u serL ist.ad d ("P au l McCartney"); userList.add("G eorge H arriso n "); re q u e st.se tA tt r ib u te ( " lis tu s e r s " , u s e rL ist); return "/W E B -IN F/pages/listusers.jsp"; } } Obiekt akcji zwraca wartość do kontrolera, a ten odbiera lokalizację strony, do której powinien skierować obiekty żądania i odpowiedzi. S tring view = a c tio n .e x e cu te (re q u e st, response); getS erv letC ontext().getR equestD ispatcher(view ).forw ard(request, response); Na listingu 14.4 kod JSP pobiera zm ienną requestScope strony i obiekt u s e rL is t utworzony w L istU serA ction. Następnie iteruje przez kolekcję i wyświetla nazwy użytkowników. Listing 14.4. Strona listuser.jsp generująca stronę zażądaną przez użytkownika <%@ page language="java" contentType="text/htm l; charset=ISO-8859-1" pageEncoding= ^"ISO-8859-1"%> <%@ ta g lib u ri= "h ttp ://ja v a .s u n .c o m /js p /js tl/c o r e " pre fix ="c" %> < title > L is ta użytkowników Nasi użytkownicy:
$ { listu s e rs} Przedstaw iony przykład to prosta im plem entacja wzorca MVC. W następnym podrozdziale pokazujemy, jak zaim plem entow ać podobną aplikację przy użyciu narzędzi dostępnych w Javie EE 7.
206
I
ROZDZIAŁ 14. Wzorzec Model - Widok - Kontroler
Implementacja wzorca MVC w Javie EE Zwykła implementacja wzorca MVC wymagała napisania logiki kontrolera, mapowania adresów URL na klasy kontrolujące oraz stworzenia dużej ilości zapychającego kodu. W najnowszej wersji Javy EE kod ten został już napisany i zadaniem programisty jest tylko skupienie się na widoku i modelu. Implementacje kontrolera dostarcza serwlet FacesServlet.
Serwlet FacesServlet Serwlet FacesServlet obsługuje żądania użytkowników i dostarcza widoki użytkownikom. Obsługuje też cykl życia aplikacji sieciowych, w których interfejs użytkownika jest utworzony przy użyciu JSF. Przechodzą przez niego wszystkie żądania. Serwlet ten jest integralną częścią JSF i m ożna go konfigurować, w razie gdyby trzeba było zmienić m etodę jego działania w nietypowy sposób. Dzięki stosowanej koncepcji konwencji zamiast konfiguracji domyślne ustawienia są używane we wszystkich przypadkach oprócz najbardziej skomplikowanych.
KONFIGURACJA SERWLETU FACESSERVLET Jeśli trzeba zmienić konfigurację serwletu FacesServlet, należy to zrobić w pliku faces-config.xml. W JSF 2.2 wprowadzono możliwość zmieniania najczęściej używanych ustawień konfiguracyjnych za pom ocą adnotacji, przez co plik faces-config.xml jeszcze bardziej stracił na znaczeniu.
Implementacja wzorca MVC przy użyciu serwletu FacesServlet Przepiszemy poprzedni przykład przy użyciu serwletu FacesServlet i JSF. Do deklaracji widoków dla JSF używa się faceletów. Facelety zastępują strony JSP i składają się z kodu XHTML i CSS. W JSF istnieje pojęcie ziarna wspierającego (ang. backingbean). Jest to zwykły obiekt Javy (POJO) opatrzony adnotacjami @Named i @RequestScope. Ziarna takie są dostępne na stronach JSF przez czas trwania żądania HTTP. W JSF program ista może odwoływać się do ich metod bezpośrednio. N a listingu 14.5 przedstawiono klasę ListUserAction przepisaną jako ziarno wspierające. Listing 14.5. Klasa ListUserAction przepisana jako ziarno wspierające package com.devchronicles.mvc.javaee; import import import import
java.util.ArrayList; j ava. ut il. Lis t; javax.enterprise.context.RequestScoped; javax.inject.Named;
@RequestScoped
Implementacja wzorca MVC przy użyciu serwletu FacesServlet
@Named public c la ss ListUsersAction { p riv a te List u serL ist = new ArrayList<>(); public List g etU serL ist() { return u serL ist; } public S tring execute() { userL ist.add("John Lennon"); userL ist.add("R ingo S ta rr" ); u serL ist.ad d ("P au l McCartney"); u s e rL ist.a d d ("George H arriso n "); return "/W EB-IN F/pages/listusers.xhtm l"; } } Ponieważ wszystkie ziarna wspierające są oznaczone przynajmniej adnotacjami @Named i @RequestScope, utworzono adnotację stereotypow ą nadającą ziarnu wszystkie cechy ziarna wspierającego. Adnotacja ta nazywa się @Model. Następną czynnością jest utworzenie pliku index.xhtml. Zastępuje on plik home.jsp i jest wywoływany wprost z przeglądarki. Celem tego pliku JSF jest wywołanie metody execute na obiekcie L istU sersA ctio n , który przygotowuje dane dla widoku listusers.xhtml. Na listingu 14.6 pokazano zawartość pliku index.xhtml. Listing 14.6. Strona główna przykładu implementacji wzorca MVC < h :h ead > < title> W itaj!< /title> < /h : head> Witaj w naszej w itrynie!
Kliknij, aby w yśw ietlić .
W elemencie akcji użyliśmy znacznika h:commangLink oraz ziarna wspierającego i m etody execute. M etoda ta jest wywoływana bezpośrednio w JSF. Generuje ona listę użytkowników, zwraca lokalizację widoku do wyrenderowania tej listy oraz wywołuje metodę g e tU se rL ist i wyświetla listę użytkowników. Pokazano to na listingu 14.7.
| 207
208
I
ROZDZIAŁ 14. Wzorzec Model - Widok - Kontroler
Listing 14.7. Widok renderujący dane z modelu < title > L is ta użytkowników Nasi użytkownicy:
< u i:rep eat value= "#{listU sersA ction.userL ist}" v ar= "listu se rs">
< /u i:rep eat> W ziarnie wspierającym klasa akcji jest wykorzystywana pod zaczynającą się od małej litery nazwą lis tU s e rs A c tio n , a z nazwy m etody g e tU se rL ist usunięto słowo get. Jeśli nazwa metody zaczyna się od słowa g et, to m ożna je opuścić. Po wdrożeniu tej aplikacji widok index.xhtml wyrenderuje łącze, którego kliknięcie spowoduje wyświetlenie następującej listy użytkowników: Nasi użytkownicy: John Lennon Ringo S ta rr Paul McCartney George Harrison Stworzyliśmy kompletną witrynę internetową na podstawie wzorca MVC przy użyciu najnowszych funkcji Javy EE 7.
Gdzie i kiedy używać wzorca MVC Wzorzec MVC najczęściej jest wykorzystywany w aplikacjach sieciowych, chociaż można go stosować wszędzie tam, gdzie trzeba oddzielić logikę prezentowania widoku od logiki biznesowej. W rzeczywistości wzorzec MVC tak się zakorzenił w architekturze aplikacji sieciowych, że większość osób nie wyobraża sobie nieużywania go. Nie ulega wątpliwości, że dwie największe korzyści z zastosowania tego wzorca są bardzo ważne. Rozdzielenie spraw umożliwia tworzenie elastycznych aplikacji, a rozdział składników pozwala tworzyć je niezależnie od siebie. N a przykład jeden zespół może pracować nad logiką prezentacji, a inny nad logiką biznesową i obiektami dziedzinowymi.
Podsumowanie
| 209
Podsumowanie O wzorcu MVC wypowiada się wiele osób, które wyrażają swoje zdanie na jego temat, opisują własne techniki jego implementacji, a nawet próbują powiedzieć, do czego może być przydatny. W tym rozdziale przedstawiliśmy własne opinie na ten temat. Czasami trudno jest dostrzec prawdziwe korzyści płynące ze stosowania tego wzorca. Przede wszystkim nie zapom inaj o podstawach: celem wzorca MVC jest oddzielenie logiki prezentacyjnej od biznesowej. Jeśli Twój program spełnia te warunki, oznacza to, że prawidłowo zaimplementowałeś wzorzec MVC. W rozdzieleniu logiki prezentacji od logiki biznesowej chodzi o utrzymanie wyraźnej granicy między obiektami dziedzinowymi modelującymi problem i prezentacją tej logiki. Rozdział taki pozwala na przedstawianie danych biznesowych na wiele różnych sposobów jednocześnie i bez potrzeby inform owania obiektu dziedzinowego o tym, w jaki sposób będzie zaprezentowany. Obiekt taki m ożna wyświetlić na ekranie w jednym z wielu formatów albo wysłać do pliku W orda lub Excela.
ĆWICZENIA 1.
Rozbuduj przykład opisany w tym rozdziale o dodatkowe widoki listy użytkowników.
210 | ROZDZIAŁ 14. Wzorzec Model - Widok - Kontroler
15 Inne wzorce projektowe w Javie EE
ZAWARTOŚĆ ROZDZIAŁU:_______ > g n ia z d a siecio w e ; > w a rstw y p o śre d n ie w ia d o m o śc io w e ; > m ik ro u s łu g i i m o n o lity.
PRZYKŁADY KODU DO POBRANIA Pliki z kodem źródłowym przykładów z tego rozdziału znajdują się w archiwum, które można pobrać z serwera FTP wydawnictwa Helion pod adresem: ftp://ftp.helion.pl/przyklady/javeez.zip. Pliki znajdują się w folderze r15, a ich nazwy odzwierciedlają kolejne fragmenty rozdziału.
W tym rozdziale opisujem y niektóre zalety korzystania z technologii Java EE. M ożna go traktow ać jako zbiór wszystkich ważnych tem atów, które nie pasowały tematycznie do żadnego z wcześniejszych rozdziałów. Najpierw opisujemy gniazda sieciowe, które są bardzo ciekawą nowością w Javie EE. Potem przechodzimy do warstw pośrednich do przekazywania wiadomości, a na końcu zamieściliśmy parę słów o spokrewnionej z nim i architekturze mikrousługowej. Dajemy Ci w prezencie torbę technicznych cukierków!
212
I
ROZDZIAŁ 15. Inne wzorce projektowe w Javie EE
Co to są gniazda sieciowe G niazda sieciowe (ang. WebSockets) mogą być najciekawszą nowinką internetową od czasów technologii Ajax. Popularność zdobyły wraz z pojawieniem się technologii HTML5 i są obsługiwane przez wiele sieciowych systemów szkieletowych. Jednak opracowanie stabilnej i kompatybilnej specyfikacji WebSockets zajęło sporo czasu. Model HTTP został zaprojektowany wiele lat przed tym, jak internet stał się popularny. Jego podstawy stanowiły prosta specyfikacja i prosty projekt. W tradycyjnym modelu HTTP klient otwiera połączenie z serwerem i wysyła do niego żądanie1 typu GET, POST, PUT lub DELETE, a serwer zwraca właściwą odpowiedź. Podjęto wiele prób zmodyfikowania sposobu działania standardowego protokołu HTTP, np. Ajax, oraz opracowania nowego modelu, np. SPDY. Tradycyjny model HTTP jest nieporęczny dla prawie każdej aplikacji, której działanie nie polega tylko na pobieraniu i wysyłaniu danych. W yobraź sobie klienta czatowego, którego użytkownicy mogą wysyłać wiadomości w dowolnej kolejności i jednocześnie może korzystać z niego nawet kilkuset użytkowników. Standardowe podejście oparte na żądaniach i odpowiedziach nie nadawałoby się do zaimplementowania takiej aplikacji. Początkowo ograniczenia próbowano obejść przy użyciu technologii Ajax i Comet. W obu wykorzystywane jest długotrw ałe sondow anie (ang. long polling) polegające na otwarciu połączenia HTTP i utrzymywaniu jego aktywności dzięki niefinalizowaniu odpowiedzi. Dzięki gniazdom sieciowym klient może zainicjować surowe połączenie gniazdowe z serwerem i nawiązać norm alną komunikację dwustronną. Specyfikację gniazd sieciowych zawiera dokum ent JSR 356. Wszystkie klasy, interfejsy i adnotacje dotyczące tej technologii znajdują się w pakiecie j a v a x . w e b s o c k e t i jego serwerowym pakiecie podrzędnym. Aby zaimplementować gniazda sieciowe w Javie EE, należy utworzyć klasę punktu końcowego z m etodam i cyklu życia gniazda, jak pokazano na listingu 15.1. Listing 15.1. Przykładowy punkt końcowy p a c k a g e c o m .d e v c h r o n i c l e s .w e b s o c k e ts ; p u b l i c c l a s s H e llo E n d p o in t e x te n d s E n d p o in t { @ O verride p u b l i c v o id o n O p e n ( f in a l S e s s io n s e s s i o n ,
E n d p o in tC o n fig c o n f ig ) {
s e s s io n .a d d M e s s a g e H a n d le r(n e w M e s s a g e H a n d le r.W h o le < S trin g > () { @ O verride p u b l i c v o id o n M e s s a g e (S trin g msg) { try { s e s s i o n . g e t B a s i c R e m o t e ( ) .s e n d T e x t ( " C z e ś ć , " + m sg); } c a t c h (IO E x c e p tio n e) { } } } ); } }
Klasa E n d p o in t wprowadza trzy m etody cyklu życia: o n O p e n , o n C lo s e oraz o n E r r o r . Klasa rozszerzająca musi implementować przynajmniej metodę o n O p en . Zdefiniowany punkt końcowy m ożna wdrożyć na dwa różne sposoby: przez konfigurację lub programowo. 1 Lista w szystkich m e to d H T T P: GET, POST, DELETE, PUT, PATCH, OPTION, HEAD, TRACE oraz CONNECT.
Co to są gniazda sieciowe
| 213
Aby programowo wdrożyć kod z listingu 15.1, aplikacja musi wykonać następujące wywołanie: S e r v e rE n d p o in tC o n fig .B u ild e r .c r e a te ( H e llo E n d p o in t.c la s s ,
" / h e l l o " ) . b u i l d ( );
W drożone gniazdo sieciowe jest dostępne pod adresem: ws://://hello. Lepszym sposobem jest zastosowanie konfiguracji adnotacyjnej. Na listingu 15.2 znajduje się definicja poprzedniego punktu końcowego utworzona przy użyciu adnotacji. Listing 15.2. Przykład punktu końcowego z adnotacjami p a c k a g e c o m .d e v c h r o n i c l e s .w e b s o c k e ts ; @ S e r v e r E n d p o i n t ( " /h e l lo " ) p u b l i c c l a s s H e llo E n d p o in t { @OnMessage p u b l i c v o id o n M e s s a g e (S e s s io n s e s s i o n , S t r i n g msg) { try { s e s s i o n . g e t B a s i c R e m o t e ( ) .s e n d T e x t ( " C z e ś ć , " + m sg); } c a t c h (IO E x c e p tio n e ) { } } }
Technika ta pozwala na używanie adnotacji i jednocześnie zachowanie możliwości korzystania ze zwykłych obiektów Javy, ponieważ nie wymaga rozszerzania żadnej klasy podstawowej. Punkt końcowy z adnotacjami m a takie same m etody cyklu życia co punkt przedstawiony na listingu 15.1, ale dodatkowo wprowadza metodę o n M e s s a g e . Zamiast implementować metodę onO pen i dodawać procedurę obsługi o n M e s s a g e , wystarczy zaimplementować oznaczoną adnotacją metodę o n M e s s a g e . W razie potrzeby adnotacją @ OnM essage m ożna oznaczyć kilka metod, aby móc odbierać różne typy danych, takie jak np. S t r i n g i B y t e B u f f e r . O d strony klienta implementacja gniazd sieciowych zależy od używanych sieciowych systemów szkieletowych. Poniżej przedstawiona jest prosta wersja w JavaScripcie: v a r w eb S o ck et = new W e b S o c k e t ( 'w s : / / 1 2 7 . 0 .0 . 1 : 8 0 8 0 / w e b s o c k e t s / h e l l o ') ; w e b S o c k e t.s e n d ( " ś w i e c i e . " ) ;
Lepszym przykładem jest wysłanie skomplikowanego obiektu w formacie JSON, który potem m ożna zamienić na norm alny obiekt, jak w poniższym przykładzie: v a r msg = ty p e : te x t: d a te : };
{ "m e s sa g e " , " ś w ie c ie ." , D a te .n o w ()
w e b S o c k e t .s e n d ( J S O N .s t r in g i f y ( m s g ) ) ; w e b S o c k e t.o n m e ss a g e = f u n c t i o n ( e v t )
{ /* oczekiw ane pow ita n ie */ };
Gniazda sieciowe są doskonałym rozwiązaniem do tworzenia aplikacji sieciowych, w których trzeba stale i asynchronicznie przekazywać wiadomości między klientem i serwerem. Java EE zapewnia łatwą implementację gniazd sieciowych i znacznie większą ilość opcji konfiguracyjnych niż opisano w tym rozdziale. Jeśli zaciekawiła Cię ta technologia, przeczytaj kurs Javy EE firmy Oracle2, w którym szczegółowo opisano metody program owania gniazd sieciowych przy użyciu API Javy. 2 K urs obsługi A PI g niazd sieciow ych firm y O racle; http://docs.oracle.eom /javaee/7/tutorial/w ebsocket.htm .
214
I
ROZDZIAŁ 15. Inne wzorce projektowe w Javie EE
Co to jest warstwa pośrednia do przekazywania wiadomości Składniki systemu Java EE kom unikują się ze sobą w sposób synchroniczny. Łańcuch wywołań zaczyna się w ziarnie EJB, przechodzi do obiektu dostępu do danych (DAO), potem do encji itd., wreszcie do celu końcowego. Wszystkie składniki tego łańcucha wywołań muszą być dostępne i gotowe do odbierania wywołań, a składnik wywołujący musi czekać na odpowiedź, zanim przejdzie dalej. Powodzenie wywołania zależy od dostępności wszystkich składników. Jak pokazaliśmy w rozdziale 9., „A synchroniczność”, wywołanie m etody asynchronicznej nie wymaga, aby obiekt wywołujący czekał na odpowiedź. Obiekt ten może kontynuować działanie, podczas gdy m etoda asynchroniczna tworzy własny łańcuch wywołań. O prog ram o w an ie p ośred n ie do p rzesyłania w iadom ości (ang. message-oriented m iddlew are — MOM) to rodzaj bufora znajdującego się między systemami i umożliwiającego opóźnienie komunikacji, jeśli dany składnik nie działa. W iadomości są dostarczane natychmiast, gdy wszystkie składniki stają się dostępne. W ywołania są tłumaczone na wiadomości i wysyłane przez system obsługi wiadomości do składnika docelowego, który je przetwarza i może na nie odpowiadać. Jeżeli składnik docelowy jest niedostępny, wiadomości są ustawiane w kolejce w oczekiwaniu na jego udostępnienie. Gdy składnik jest dostępny, wiadomości są przetwarzane. Na jednym końcu łańcucha znajduje się producent tłumaczący wywołanie na postać nadającą się do przesłania jako wiadomość, a na drugim końcu jest konsum ent oczekujący na tę wiadomość. Konsum enci i producenci są od siebie niezależni, ponieważ nic o sobie nawzajem nie wiedzą. Składniki te nie muszą być nawet napisane w tym samym języku programowania ani znajdować się w tej samej sieci — równie dobrze mogą być rozproszone na wielu zewnętrznych serwerach. System MOM składa się z czterech rodzajów elementów: wiadomości, konsumentów, producentów i brokerów. Producenci generują wiadomości i przekazują je do brokerów, ci zaś wysyłają je do miejsc docelowych, gdzie są przechowywane do czasu, aż pojawi się klient, który je przetworzy. Wyróżnia się dwie architekturalne implementacje MOM — punkt do punktu i publikacja-subskrypcja. W implementacji punkt do punktu producent wysyła wiadomość do miejsca docelowego zwanego kolejką. W kolejce wiadomość czeka, aż odbierze ją konsum ent, który potwierdzi, że została przetworzona. Gdy to się stanie, wiadomość zostaje usunięta z kolejki. Na rysunku 15.1 ukazano producenta wstawiającego wiadomość W1 do kolejki i konsumenta odbierającego tę wiadomość w celu jej przetworzenia. W tej implementacji wiadomość jest przetwarzana tylko przez jednego konsumenta.
Rysunek 15.1. Implementacja punkt do punktu W implementacji publikacja-subskrypcja cel nazywany jest tem atem (ang. topic). Producent publikuje wiadomość w temacie i wszyscy konsumenci subskrybujący ten tem at otrzymują jej kopię. Pokazano to na rysunku 15.2, na którym wiadomości W1 i W2 zostały opublikowane w temacie T1 oraz są konsumowane przez konsum entów K1 i K2, a wiadomość W3 została opublikowana w temacie T2 i jest konsum owana przez konsum entów K2 i K3.
Co to jest architektura mikrousługowa
| 21 5
Rysunek 15.2. Implementacja publikacja-subskrypcja Java EE zapewnia wygodny w użyciu interfejs API do tworzenia takich implementacji o nazwie JMS (ang. Java Message Service). Jest to zbiór interfejsów opisujących sposoby tworzenia wiadomości, dostawców i konsum entów . W przypadku im plem entacji w kontenerze EJB ziarna MDB (ang. message-driven bean) służą jako asynchronicznie wywoływane odbiorniki wiadomości JMS.
Co to jest architektura mikrousługowa Przez kilka ostatnich lat wiele dyskusji toczy się na tem at wzorca architektury m ikrousługow ej. Jego głównym założeniem jest zaprojektowanie dużej skalowalnej aplikacji składającej się z niewielkich spójnych usług, które mogą się zmieniać, a nawet być kompletnie przepisywane w czasie życia aplikacji. Nie jest to żadna nowość. Podobne założenia są obecne we wzorcu SOA (ang. Service Oriented Architecture), którego programiści używają już od wielu lat. Istotą mikrousług jest pomysł, że każda usługa pow inna być m ała — najwyżej kilkaset linijek kodu. Celem jest rozłożenie dużej monolitycznej aplikacji na mniejsze aplikacje, aby rozwiązać problemy podczas programowania i rozwoju. W dalszej części tego podrozdziału przedstawiamy powody, dla których można zdecydować się na zastosowanie architektury mikrousługowej, jej zalety i wady oraz porównujem y ją z mającą już ugruntow aną pozycję architekturą monolityczną.
Architektura monolityczna Najpopularniejszym i najstarszym sposobem wdrażania aplikacji jest zebranie wszystkich zasobów, składników i plików klas w pojedyncze archiwum WAR (ang. web application archive) lub EAR (ang. enterprise archive) i wysłanie tego na serwer. Typowa aplikacja do obsługi księgarni może zawierać składniki do zarządzania kontam i użytkowników, przetwarzania płatności, kontrolowania zapasów książek, obsługiwania świadczonych usług oraz generowania widoków frontowych. Wszystkie te elementy tworzy się w ram ach jednej monolitycznej aplikacji, którą następnie pakuje się i wdraża na serwerze. Na rysunku 15.3 pokazano uproszczoną reprezentację takiego monolitu.
216
| ROZDZIAŁ 15. Inne wzorce projektowe w Javie EE
Rysunek 15.3. Architektura monolityczna Moduły reprezentujące składniki są spakowane w jedno archiwum i wdrażane jako pojedyncza monolityczna aplikacja. Taki sposób rozwijania i wdrażania aplikacji jest łatwy, ponieważ trzeba przetestować tylko jeden program . Także środowiska program istyczne i inne narzędzia dla program istów są tworzone z myślą o architekturze monolitycznej. Jednak mim o niewątpliwych zalet tej architektury aplikacje tworzone w ten sposób są z reguły bardzo duże. Programiście łatwiej jest ogarnąć umysłem, zrozum ieć i obsłużyć mniejszą aplikację. Duże program y są skomplikowane i trudne do zrozumienia, w szczególności dla tych, którzy niedawno przyłączyli się do zespołu. Dokładne zrozumienie wszystkich niuansów takiej aplikacji może zająć wiele tygodni, a nawet miesięcy. Często wdrażanie jest niepraktyczne, ponieważ wymaga koordynacji prac wielu programistów i niejednokrotnie różnych działów firmy. Przygotowanie wszystkiego może trwać wiele godzin, a nawet dni, co utrudnia testowanie nowych funkcji i poprawianie błędów. Poważną wadą monolitycznych projektów jest też to, że trudno w razie potrzeby zmienić technologię lub system szkieletowy. Aplikację stworzono na podstawie pewnych decyzji podjętych na samym początku projektu. Jesteśmy na nie skazani i nawet gdy pojawi się nowa technologia pozwalająca rozwiązać nasz problem w elegantszy lub efektywniejszy sposób, trudno będzie się na nią przestawić. Przepisanie całej aplikacji rzadko kiedy jest wykonalne. Krótko mówiąc: architektura m onolityczna opornie poddaje się skalowaniu.
Co to jest architektura mikrousługowa
I 217
Skalowalność Skalowalność to zdolność aplikacji do wzrostu (i zmniejszania się) w odpowiedzi na zmiany popytu na jej usługi bez zauważalnego wpływu na wygodę użytkownika. Źle zaprojektowany sklep internetow y szybko straci klientów i dlatego właśnie skalowalność jest tak ważna. Rozwiązaniem pierwszego wyboru jest skalowanie horyzontalne i zduplikowanie aplikacji na wielu serwerach oraz równoważenie ruchu w celu zapewnienia jej jak największej dostępności poprzez utrzymywanie pasywnego systemu, który uaktywnia się w razie awarii aktualnie używanego. Taka metoda skalowania zwiększa możliwości i dostępność aplikacji. Nie jest kosztowna pod względem rozwojowym, ale wymaga większych nakładów na hosting i obsługę serwisową3. Aplikację m ożna też skalować wgłębnie (według osi Z). W takim przypadku, podobnie jak w skalowaniu poziomym, kod powiela się na kilku serwerach, ale każdy serwer odpowiada tylko za cząstkę całości danych. Ruchem danych do odpow iednich serwerów sterują specjalne m echanizm y wykorzystujące informacje o typie użytkownika lub klucze główne. Pod względem zysków wydajności skalowanie według osi Z jest porównywalne z poziomym, ale dodatkowo wprowadza koszt rozwojowy związany ze zm ianą architektury aplikacji. Żaden z opisanych sposobów nie rozwiązuje problem u rosnącej złożoności aplikacji. Do tego potrzebne jest skalowanie pionowe. Aplikację można też skalować według osi Y (pionowo). Polega to na rozłożeniu programu na funkcje, usługi lub zasoby. Sposób wykonania tego zależy wyłącznie od nas oraz od sytuacji, chociaż często wybieranym rozwiązaniem jest podział według przypadków użycia. Chodzi o to, że każda część kompozycji pow inna obejmować niewielki zbiór spokrewnionych ze sobą form aktywności. Skalowanie według osi X, Y i Z przedstawia się w postaci sześcianu skalowania AKF4 ukazanego na rysunku 15.4. Podział wedtug funkcji, usług lub zasobów
Skalowanie według osi Y dekompozycja funkcjonalna
Monolit (aplikacja lub system)
Skalowanie według osi X powielanie poziome
Rysunek 15.4. Sześcian AKF przedstawiający skalowanie według osi X, Y i Z 3 K oszt rozw ojow y m oże się też pojaw ić, jeśli w system ie będą w ykorzystyw ane d ane sesji H T T P i nie zapew ni się klastrow ego rozw iązania dla replikacji sesji H T T P. 4 M a rtin L. A bbott, M ichael T. Fisher, The A r t o f Scalability: Scalable W eb Architecture, Processes, and O rganizations fo r the M odern Enterprise, 1 stycznia 2009 r.
218
| ROZDZIAŁ 15. Inne wzorce projektowe w Javie EE
Dekompozycja na usługi W architekturze mikrousługowej monolityczną aplikację rozkłada się według osi Y na usługi zaspokajające pojedynczy przypadek użycia lub na zbiór spokrew nionych elementów funkcjonalności. Usługi te są powielane na kilku serwerach i umieszczane za systemem równoważenia obciążenia — podział według osi X. M echanizm zapisywania danych można skalować według osi Z przez podział danych na podstawie klucza głównego. Gdyby dokonano dekompozycji aplikacji z rysunku 15.3 według osi Y, otrzymano by architekturę przedstawioną na rysunku 15.5.
Widok konta użytkownika \
Widok magazynu /
\ \ \
\
Widok zamówień
/
\
\
\ \
i
r wn L.
■ Dane konta użytkownika
Usługa kontroli zapasów
Obsługa UŻ> 'tkowników
r L
■
r [ H L Obsługa ,płatności
u
■
1 1 1 Dane dotyczące zapasów
Dane klientów
k ^
j
^A
k ^
Dane dotyczące płatności
^A
Rysunek 15.5. Dekompozycja według osi Y
W idoki frontowe zostały podzielone na osobne aplikacje wykorzystujące funkcjonalność kilku usług zapleczowych. Usługi te zostały wyodrębnione z monolitycznej aplikacji i zamienione w samodzielne aplikacje pracujące na własnych zbiorach danych. Podziału według osi Z dokonuje się poprzez rozdzielenie danych, a podziału według osi X — przez klastrowanie i równoważenie obciążenia. Wiesz już, na czym polega dekompozycja monolitycznej aplikacji na mikrousługi i jak bardzo ważna jest skalowalność dla ciągłości działania aplikacji. Poniżej znajduje się bardziej szczegółowy opis korzyści ze stosowania architektury mikrousługowej oraz kosztów, jakie należy w związku z tym ponieść.
Zalety architektury mikrousługowej Z perspektywy rozwojowej korzyści ze stosowania architektury mikrousługowej wynikają z niewielkich rozmiarów i stopnia skomplikowania małych aplikacji. Aplikacje te są zrozumiałe dla program isty i łatwo się nad nim i panuje w środowiskach programistycznych. Duża aplikacja złożona z setek m odułów może bardzo długo się ładować, co znacznie pogarsza produktywność.
Co to jest architektura mikrousługowa
| 219
W drażanie aplikacji mikrousługowej trwa krócej i na ogół nie wymaga współpracy wielu zespołów. Jako że każda usługa jest samodzielna, lokalne zmiany w kodzie nie mają wpływu na pozostałe usługi, co umożliwia ciągłe rozwijanie program u. N ad każdą mikrousługą może pracować wyznaczony zespół programistów, którzy zajmą się wdrażaniem i spełnianiem wymogów niezależnie od pozostałych zespołów. Interfejs użytkownika z reguły nie jest powiązany z systemem zaplecza — programiści tego systemu często nie mają żadnej styczności z kodem frontowej części aplikacji. Jeśli ktoś programuje przy użyciu interfejsu API typu REST (zob. rozdział 13., „REST-owe usługi sieciowe”), to musi tylko trzymać się uzgodnień dotyczących sposobu reprezentacji zasobów, a kwestie związane z implementacją interfejsu użytkownika w ogóle go nie obchodzą. Umożliwia to przeprowadzenie prawdziwego rozdziału spraw. Jeśli chodzi o wydajność aplikacji, największą korzyścią jest możliwość wdrożenia każdej mikrousługi w specjalnie przygotowanym dla niej środowisku. Każda m ikrousługa może mieć inne wymagania dotyczące zasobów, więc w ten sposób program ista może bardzo precyzyjnie te zasoby alokować. Aplikacja monolityczna jest wdrażana w jednym środowisku ze wspólnymi zasobami. Kolejną zaletą jest zwiększenie odporności systemu na awarie oraz stopnia izolacji. Awaria w jednej mikrousłudze nie upośledza działania pozostałych mikrousług, więc aplikacja może nadal działać. W systemach wykorzystujących MOM do komunikacji między usługami wiadomości przeznaczone dla usługi, która uległa awarii, czekają w kolejce, aż usterka zostanie usunięta i usługa znowu zacznie pobierać dane do przetworzenia. Jeśli aplikacja jest skalowana poziomo, w świadczeniu usług nie m a żadnej przerwy, ponieważ przetwarzanie wiadomości przejmie jeden z duplikatów usługi. W aplikacji monolitycznej taka usterka spowodowałaby unieruchomienie całego systemu. Spośród wszystkich korzyści płynących ze stosowania architektury mikrousługowej do najczęściej omawianych należy łatwość zmiany technologii. Jako że każda m ikrousługa jest niewielka, jej przepisanie nie sprawia poważniejszych problemów. W istocie nowe mikrousługi można pisać w dowolnych językach programowania, co pozwala na wybór najodpowiedniejszej technologii do rozwiązania określonego problemu. Decyzje technologiczne podejmowane na początku pracy nie determ inują wszystkich działań w późniejszym czasie.
Nie ma nic za darmo Oczywiście korzyści ze stosowania architektury mikrousługowej nie są darmowe. Łatwość, z jaką tworzy się nowe usługi, sprawia, że ich liczba może szybko urosnąć. Z piętnastu mikrousług może zrobić się trzydzieści i więcej, zwłaszcza gdy policzy się różne wersje tej samej mikrousługi. Sprawia to wiele problemów. Odpowiedzialność za działanie może spaść na zespół programistyczny. Jeśli do obsłużenia jest tylko kilka usług, to nie m a problemu, ale każda kolejna usługa coraz bardziej komplikuje zadanie. Aby dopilnować wdrożenia i obsługi wszystkich mikrousług, trzeba poczynić spore inwestycje. Należy zautomatyzować procesy, aby odciążyć specjalistów od wdrażania i konserwacji. Może powstać luka w wiedzy, którą trzeba będzie uzupełnić, a to oznacza kolejne koszty operacyjne. Przekrojowe zmiany semantyki wymuszają zmiany w kodzie wszystkich mikrousług. Wprowadzanie takich zmian może być czasochłonne, a dodatkowo potem trzeba jeszcze ponieść koszty na powtórzenie testów. Przykładami tego typu zm ian są modyfikacje kontraktów interfejsowych i formatów wiadomości. Ich wprowadzanie wymaga koordynacji pracy wszystkich zespołów. Analogicznie: jeśli nie zmieni się interfejsu lub form atu wiadomości we wczesnej fazie trwania projektu, to każda kolejna m ikrousługa będzie powodować tylko dodatkowe komplikacje.
220
I
ROZDZIAŁ 15. Inne wzorce projektowe w Javie EE
Każdy program ista uczy się, że nie należy powielać kodu. To prawda. Ale w środowisku mikrousługowym ryzyko wystąpienia duplikatów jest wysokie. Aby uniknąć ścisłych powiązań składników i powstania wielu zależności, czasami trzeba zduplikować pewne fragmenty kodu, a każdy z tych fragm entów musi być potem przetestowany i obsługiwany. Czasami wspólny kod można przenieść do biblioteki, ale jest to niemożliwe w środowiskach, w których używa się różnych języków programowania. Środowisko mikrousługowe nie jest pozbawione typowych dla systemów rozproszonych wad zawodności i złożoności. Każda usługa może być hostowana w systemie rozproszonym, komunikować się z resztą systemu poprzez sieci dręczone przez duże opóźnienia, braki zgodności różnych składników, zawodnych dostawców, problemy sprzętowe itd. Konieczne jest ciągłe m onitorowanie działania sieci.
Wnioski Architektura monolityczna jest wykorzystywana od wielu lat i równie dobrze sprawdza się przy tworzeniu większych, jak i mniejszych aplikacji. Programy w tym stylu łatwo się tworzy i testuje, ponieważ środowiska programistyczne są do tego przystosowane. Ale, jak pokazaliśmy, aplikacje takie trudno się skaluje i rozwija. Problematyczne jest wprowadzanie nowych technologii, a refaktoryzacja wymaga dużych nakładów. Architektura mikrousługowa zakłada podzielenie aplikacji na logiczne usługi reprezentujące elementy funkcjonalności. Ich niewielki rozmiar sprawia, że są łatwiejsze do zrozumienia dla programistów. Rozwój i wdrażanie aplikacji to procesy ciągłe. Skalowalność jest cechą charakterystyczną tej architektury i nie trzeba kurczowo trzymać się wszystkich decyzji technologicznych podjętych na początku.
Kilka antywzorców na zakończenie Celem napisania tej książki było zapełnienie luki dzielącej klasyczne wzorce projektowe i Javę EE. Na tem at antywzorców napisano wiele książek, ale nie zaszkodzi wymienić paru z nich także tutaj. Antywzorce to z reguły przykłady nieprawidłowego wykorzystania jednego lub kilku wzorców projektowych. Doświadczony program ista Javy EE bez trudu poda więcej nazw antywzorców niż wzorców projektowych. Poniżej znajduje się opis kilku najczęściej spotykanych.
Uberklasa Nie ma chyba projektu bez gigantycznej klasy spełniającej wiele różnych funkcji. Istnienie takiej klasy stanowi złamanie nie tylko podstawowych zasad Javy EE, ale i programowania obiektowego. Dlatego należy unikać tego typu rozwiązań jak ognia. Do tej samej kategorii zaliczają się usługi obciążone zbyt dużą ilością obowiązków. Jeśli ktoś nie jest wielbicielem obiektowości, to trudno, ale skoro używa języka obiektowego, to dobrze by było, gdyby tworzył spójne i niewielkie klasy. Sam antywzorzec był opisywany przez różnych programistów, ale nazwę Uberklasa (ang. uber class) wymyślił Reza Rahman.
Kilka antywzorców na zakończenie
| 221
Architektura Lazani W Javie EE od samego początku zalecano stosowanie warstw, przez co prawdopodobnie powstało zbyt wiele interfejsów i pakietów. Choć może się wydawać, że wzorzec ten stanowi rozwiązanie problem ów Uberklasy i architektury monolitycznej, w rzeczywistości najczęściej tylko niepotrzebnie jeszcze bardziej wszystko komplikuje. Architektura Lazani w program ow aniu obiektowym jest czymś podobnym do kodu spaghetti w program owaniu strukturalnym . Przesada w stosowaniu abstrakcji w niczym nie pomaga. Interfejsy i rozluźnianie powiązań między składnikami program u to doskonałe narzędzia, pod warunkiem że stosuje się je w odpowiedni sposób, we właściwym kontekście i tylko wtedy, gdy rzeczywiście jest to potrzebne. Antywzorzec ten opisało wielu programistów pod różnymi nazwami, np. jako Kod Bakławy (ang. Baklava Code). N atomiast nazwa Lazania najprawdopodobniej została wymyślona przez Adam a Biena5, gorącego przeciwnika używania interfejsów bez potrzeby.
Pan Kolumb Prawie każdy doświadczony programista Javy EE chce wynaleźć lub zaimplementować rozwiązanie doskonałe. W większości przypadków kończy się na mniej lub bardziej udanych próbach wyabstrahowania lub utw orzenia lepszego interfejsu do powszechnie używanej biblioteki, np. do obsługi dzienników lub testowania. W ekstremalnych przypadkach ktoś może nawet przepisać od nowa ważną część funkcjonalności od lat wspieranej przez społeczność open source, np. warstwę mapowania obiektowo-relacyjnego. Choć poszukiwanie nowych rozwiązań jest rzeczą godną pochwały, wynajdywanie po raz kolejny tego, co już dawno zostało wynalezione, jest tylko stratą czasu. Jeśli masz zamiar napisać nowy system do obsługi dzienników lub mapowania obiektowo-relacyjnego, to lepiej, żebyś miał ku tem u naprawdę bardzo dobre powody. Jeśli ich nie masz, to po prostu przepiszesz od nowa produkt o ugruntowanej pozycji i pewnie skończy się to tak, że będziesz musiał go samodzielnie obsługiwać, testować i rozwijać w przyszłości. Zanim przystąpisz do pisania jakiegokolwiek projektu od początku, zawsze dokładnie sprawdź, czy nie m a już podobnych otwartych rozwiązań, które m ożna by było wykorzystać.
Korzyści z przyjaźni Jedną z wielkich wad technologii J2EE było przypisanie do dostawcy. Przed pojawieniem się technologii J2EE 1.4 większość serwerów dostawców współpracowała tylko z narzędziam i i środowiskami programistycznymi tego samego dostawcy. Początkowo wydawało się to korzystne, ponieważ producent oprogram owania zapewniał profesjonalne wsparcie użytkownikom swoich produktów, a narzędzia i serwery open source były obsługiwane przez społeczności. Jednak na dłuższą metę wielu program istów J2EE zaczęło się orientować, że otwarte narzędzia bez problemu nadążają za zm ianam i standardów, podczas gdy używane przez nich rozwiązania zamknięte były pod tym względem ociężałe. Nie m a nic złego w korzystaniu z profesjonalnej pom ocy i profesjonalnych usług zapewnianych wraz z narzędziami, serwerami i środowiskami programistycznymi dostarczanymi przez producentów oprogramowania, pod warunkiem że nie uzależniamy się od nich całkowicie. Jeśli w programie 5 A dam Bien — pisarz i m istrz Javy; w w w .adam -bien.com .
222
| ROZDZIAŁ 15. Inne wzorce projektowe w Javie EE
wystąpią jakieś problemy, to czasami ich rozwiązanie może być dostępne dopiero wtedy, gdy dostawca rozwiązań opublikuje aktualizację lub nową wersję swojego oprogramowania. Dlatego twórca aplikacji zawsze powinien mieć możliwość przejścia na rozwiązania innego dostawcy.
Supernowoczesność Zapaleńcy lubią wykorzystywać najnowsze technologie. Na przykład technologia WebSockets jest znana od lat, ale do dziś m a problem y ze zgodnością ze starszymi wersjami przeglądarek internetow ych. N ikt nie neguje przyjem ności, jaką sprawia uczenie się nowych rzeczy i implementowanie najnowocześniejszych rozwiązań w projektach, ale jeśli aplikacja jest przeznaczona do użytku przez odbiorcę głównego nurtu, m ożna napotkać wiele problemów z obsługą systemu. System szkieletowy lub technologię najlepiej jest wybierać po przeanalizow aniu potrzeb potencjalnych użytkowników produktu. Jeżeli ktoś pisze aplikację bankow ą dla klientów używających jeszcze Internet Explorera 6, to wykorzystanie gniazd sieciowych nie jest najlepszym rozwiązaniem (chociaż większość systemów szkieletowych WebSockets zawiera rozwiązania awaryjne). Zanim zdecydujesz się na coś, zawsze dokładnie sprawdź, czy dana biblioteka lub określony system szkieletowy są dobrze obsługiwane i odpowiednio rozwinięte.
Szwajcarski scyzoryk Klasy i pakiety pomocnicze występują w projektach powszechnie. Nie ulega wątpliwości, że do wykonywania niektórych działań matematycznych, np. zaokrąglania lub przekształcania jednostek, potrzebna jest klasa. Jeśli już mamy takie klasy pomocnicze, to powinniśmy przenieść je do jakiegoś pakietu, np. o nazwie u t i l albo helper, prawda? Nie, w rzeczywistości takie pakiety to zwykłe śmietniki. Nazwy te są tak ogólne, że do pakietów tych m ożna przenieść właściwie wszystko, każdą klasę, która nie pasuje do żadnej innej kategorii. A ponieważ taka ogólna nazwa nie niesie żadnych prawdziwych informacji, to nawet jeśli znajdujące się w pakiecie klasy nie są już potrzebne, nikt nie ośmieli się go usunąć. Jeśli stworzysz świetne narzędzie pomocnicze przydatne wszystkim, to wstaw je tam, gdzie jego miejsce, i dołącz odpowiednią dokumentację. W razie potrzeby w przyszłości będzie to można przenieść do bardziej ogólnego pakietu. Podobnie jak Lazanię, term in Utility M an — „szwajcarski scyzoryk” — wymyślił Adam Bien.
III Podsumowanie
^
Rozdział 16. Wzorce projektowe — dobre, złe i brzydkie
16 Wzorce projektowe — dobre, złe i brzydkie
ZAWARTOŚĆ ROZDZIAŁU:_______ > d o b re — ja k sto so w a n ie w z o rc ó w u łatw ia o sią g n ię c ie su k ce su ; > złe — ja k n a d u ż y w a n ie i u ży w a n ie d o n ie w ła ściw y ch c e ló w w zo rc ó w p ro w a d zi d o k ło p o tó w ; >
b rzy d k ie — ja k n iektó re „de facto" sta n d a rd y p ro w a d zą d o p o rażek.
W poprzednich częściach tej książki opisaliśmy wiele klasycznych wzorców z książki Bandy Czworga1 oraz kilka innych, które też mają szansę wejść w przyszłości do kanonu klasyki. Książka ta jest odzwierciedleniem tego, co autorzy sami chcieliby kupić, gdyby jej nie napisali. Jak to zwykle w życiu bywa, wzorce projektowe nie zawsze są najlepszym rozwiązaniem. Jeśli ktoś nie będzie wystarczająco ostrożny, łatwo może zamiast doskonałego rozwiązania otrzymać antywzorzec. W tym rozdziale opisujemy dobre, złe i brzydkie strony wzorców projektowych oraz staram y się podpowiedzieć, jak najlepiej wykorzystać znane wzorce.
Dobre — wzorce sukcesu Jak pisaliśmy już wiele razy, wzorce projektowe reprezentują mądrość zbiorową i doświadczenie wielu bardzo inteligentnych programistów. Podsuwają nam dogłębnie przeanalizowane rozwiązania, przy użyciu których m ożna usunąć wiele typowych problemów napotykanych podczas tworzenia programów. Nawet w czasach, gdy technologie programistyczne dopiero raczkowały, a konstrukcja 1 E rich G am m a, R ichard H elm , Ralph Johnson, John V lissides, W zorce projektowe. E lem enty oprogramowania obiektowego wielokrotnego użytku, H elion, 2010.
226
ROZDZIAŁ 16. Wzorce projektowe — dobre, złe i brzydkie
goto nie była uważana za nic złego, wiele projektów się nie udawało. Jedną z pierwszych ważnych publikacji na tem at inżynierii oprogramowania i zarządzania projektami była książka The Mythical M an-M onth Fredericka Brooksa, który napisał ją jako kierownik prac nad systemem OS360 firmy IBM2. Choć książka ta została wydana w 1975 r., wiele z poruszonych w niej problem ów jest wciąż aktualnych w dzisiejszych czasach. W tedy jednym z pierwszych wzorców projektowych było zdobywające właśnie popularność programowanie obiektowe. Był to właściwie zbiór zasad i wzorców projektowych ułatwiających modelowanie realnych sytuacji w kodzie w sposób prosty i efektywny. M ożna powiedzieć, że była to magiczna różdżka do projektowania, kodowania 1 obsługiwania program ów . Pionieram i wśród języków program ow ania w tych czasach były: Smalltalk, C++ i Objective-C. Mimo że Edsger Dijkstra3 stwierdził, iż „programowanie obiektowe to wyjątkowo zły pomysł, który mógł wymyślić tylko ktoś z Kalifornii”, była to pierwsza większa rewolucja, która na zawsze zmieniła sposób pisania programów. Ale oczywiście obiektowość nie była uniwersalnym rozwiązaniem wszystkich problemów. Po pierwsze, to, że ktoś używał obiektowego języka programowania, nie oznaczało automatycznie, że pisze program y zgodnie z zasadam i obiektowości. Programiści mogli (i nadal mogą) pisać program y proceduralne przy użyciu tych języków. Po drugie, skomplikowane i źle zaprojektowane obiekty gmatwały wszystko tak samo jak każdy inny nieobiektowy system. Na początku lat 90. słynna czwórka znana jako Banda Czworga: Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides, wydała książkę pt. Design Patterns: Elements o f Reusable Object-Oriented Software (polskie wydanie: Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku). Była to pierwsza publikacja zawierająca typowe rozwiązania często spotykanych problemów ujęte w postaci wzorców projektowych. W książce znalazł się opis 23 wzorców, które określano jako klasyczne oraz zilustrowano przykładami implementacji w językach Smalltalk i C++. Później różni znakomici programiści, np. Jim Coplien4, dodali do tego zbioru wiele innych wzorców projektowych. Ale wzorce projektowe są niezależne od wszelkich platform i języków programowania, dzięki czemu m ożna je zaimplementować przy użyciu w zasadzie dowolnej technologii. Są to tylko propozycje rozwiązań typowych problemów, dzięki którym program istom łatwiej jest się porozumiewać. Program ista zamiast szczegółowo opisywać, w jaki sposób zaimplementował m echanizm obsługi wywołań zwrotnych wyzwalany tylko wtedy, gdy jakiś zasób się zmieni, może powiedzieć: „Utworzyliśmy obserwatory do obserwowania x”. Twórcy języka Java, którzy pracowali w połowie lat 90., zastosowali w systemie wykonawczym swojego produktu wiele wzorców projektowych. Wykorzystywano je zarówno w implementacji wewnętrznej, jak i udostępniano na zewnątrz w samym języku przez dostarczenie domyślnych implementacji interfejsów API. W raz z Javą EE wprowadzono jeszcze więcej wzorców, z których wiele opisano w książce J2EE. Wzorce projektowe. Wydanie drugie5. Przeglądając katalogi wzorców projektowych i ucząc się przypadków ich użycia, m ożna wzbogacić wiedzę na tem at wielu typowych problemów i ich rozwiązań, zanim się je w ogóle napotka. W tej książce przytoczono wiele prawdziwych opowieści o tym, jak zastosowanie wzorców wpłynęło 2 Frederick P. Brooks ju n io r, The M ythical M an-M onth: Essays on Software Engineering, A ddison-W esley, 1975. 3 E dsger W ybe D ijkstra — h o len d e rsk i inform atyk, k tó ry w 1972 r. otrzym ał N ag ro d ę T u rin g a za w kład w rozw ój języków p rogram ow ania. 4 Jam es O. C oplien — pisarz, w ykładow ca i naukow iec p row adzący b a d an ia w dziedzinie inform atyki. 5 D eepak A lur, D an M alks, John C rupi, J2EE. W zorce projektow e. W ydanie drugie, H elion, 2004.
Złe — nadużywanie i błędne stosowanie wzorców
227
na rozwój różnych projektów. Nie są to historie wyssane z palca. Przeczytanie opisu wzorca i jego zapamiętanie nie oznacza, że automatycznie m amy magiczne rozwiązanie. Co najwyżej znajdziemy jakieś wskazówki, jak sobie poradzić z problemem, gdy już się na niego natkniemy. Zdobywając doświadczenie, bardzo szybko zaczniesz rozwiązywać problemy przy użyciu wzorców projektowych, nawet zanim wystąpią. Początkowo model program owania J2EE w dużym stopniu opierał się na konfiguracji w formacie XML i ciężkim kontenerze EJB. Ziarna m usiały rozszerzać określone klasy i implem entować wszystkie metody. Szybko dostrzeżono, że rozwiązanie to jest bardzo nieefektywne i o mały włos nie stało się ono antywzorcem. Mimo że system Spring6 zapewniał lekki kontener, w nowszych wersjach Javy EE zrezygnowano z plików konfiguracyjnych i postawiono na adnotacje wpisywane bezpośrednio w kodzie źródłowym. Lekki kontener i ziarna EJB oparte na zwykłych obiektach Javy zapewniły efektywny i łatwy do testowania model programistyczny. Do kolejnych wersji Javy EE dodawano wiele pożądanych przez program istów udogodnień, z których większość opisano w tej książce. Dodana niedawno technologia CDI (ang. Context and Dependency Injection) wprowadziła nowy kontener o bardzo elastycznych właściwościach. Przy jego użyciu m ożna z wielką łatwością zaimplementować wiele wzorców projektowych, np. Obserwator i Dekorator.
OPOWIADANIE WOJENNE Kiedy zaczynałem pracę przy projekcie Libra Eclipse, niewiele wiedziałem o systemie wtyczek środowiska Eclipse. Dlatego najpierw przeczytałem jedyną dostępną pozycję na ten temat — Eclipse: Building Commercial-Quality Plug-Ins Dana Rubela i Erica Clayberga (Addison-Wesley, 2008), a następnie od razu przeszedłem do szperania w kodzie źródłowym. Bardzo zdziwiła mnie ogólna architektura środowiska Eclipse i budowa systemu wtyczek. Wszędzie można było znaleźć przykłady użycia wzorców projektowych, jak: Adapter, Dekorator, Strategia, Pamiątka i wiele innych. Wszystkie były stosowane we właściwym kontekście oraz efektywnie i jasno zaimplementowane. Kod źródłowy środowiska Eclipse to jedno z najlepszych źródeł dobrych przykładów implementacji wzorców projektowych, z którego korzystają miliony programistów z całego świata.
Złe — nadużywanie i błędne stosowanie wzorców Kiedy pierwszy raz natknąłem się na wzorce projektowe, byłem oszołomiony. Cały następny miesiąc spędziłem na studiowaniu książki Wzorce projektowe. Rusz głow ą!, a kolejny poświęciłem oczywiście książce Bandy Czworga. Uzbroiłem się w wiedzę o wzorcach projektowych i byłem gotów do ich stosowania. Z czasem zdałem sobie nawet sprawę, że nie musiałem korzystać z dziedziczenia i wszystkie modele oraz hierarchie obiektów można budować przy użyciu dekoratorów. Stworzyłem nawet zbiór klas pomocniczych zawierający kilka singletonów, parę przekaźników wiadomości dla obserwatorów oraz trochę ogólnych dekoratorów i obserwatorów, które dołączałem do wszystkich nowych projektów. 6 O p a rty n a Javie system szkieletow y zapew niający wiele u d o g o d n ień , takich ja k w strzykiw anie zależności narzędzia do p ro g ram o w a n ia aspektow ego. 7 Eric F reem an, E lisabeth F reem an, Bert Bates, K athy Sierra, W zorce projektowe. R u sz głową!, H elion, 2010.
228
ROZDZIAŁ 16. Wzorce projektowe — dobre, złe i brzydkie
Lubiłem chwalić się swoim kodem innym program istom i pokazywać im, jakie to wyszukane techniki wykorzystuję. Ale szybko się okazało, że sposób, w jaki stosowałem wzorce projektowe, tylko niepotrzebnie komplikował mój kod oraz dodawał zbyt wiele warstw podczas wykonywania program u. Samo uproszczenie kodu powodowało, że program y zaczynały efektywniej działać. Jeśli ktoś pisze skomplikowany i wyszukany kod, to wcale nie znaczy, że jest najlepszym programistą. Poza tym kod taki nie jest optymalny ani łatwy w obsłudze. Inżynieria to sztuka stosowania odpowiednich narzędzi w odpowiednim czasie i budow ania wydajnych systemów. OPOWIADANIE WOJENNE Kiedyś na rozmowie o pracę poproszono mnie o zaimplementowanie struktury danych do obsługi transakcyjnych operacji w bazie danych. Miałem dokończyć program w domu i wysłać go e-mailem do firmy do oceny. W systemie miała być możliwość dodawania nowych wartości i zapisywania zmian po ich zatwierdzeniu. Ponadto musiała być możliwość powrotu do poprzedniego stanu bazy danych w razie usterki. W mojej głowie cały czas jakiś głos podpowiadał mi: „Pamiątka, Pamiątka!". Choć nigdy wcześniej nie używałem tego wzorca, wiedziałem, że to jest odpowiedni moment. Wzorzec ten umożliwiał zatwierdzanie zmian do bezpiecznego punktu i cofanie ich w razie potrzeby. Postanowiłem więc odświeżyć sobie wiadomości na jego temat. Napisałem klasy: Caretaker, Memento i O rig in ato r, umieściłem je w wewnętrznym pakiecie oraz zaimplementowałem logikę obsługi bazy danych wykorzystującą wewnętrzne klasy pamiątkowe. Byłem dumny ze swojego kodu. Jednak ku memu zaskoczeniu firma nie chciała dalej ze mną rozmawiać. Może szukali kogoś potrafiącego wykorzystać proste mechanizmy zapisywania i pobierania wartości? W każdym razie mój kod utwierdził mnie w przekonaniu, że umiem posługiwać się wzorcami projektowymi, nawet tymi, z których korzystam rzadko. Po kilku latach wróciłem do tego zadania i zauważyłem, że określono w nim warunek, aby używać jak najmniejszych obiektów oraz że wydajność czasu wykonywania musi wynosić O(log N). Mój kod był czytelny, przejrzysty i łatwy w obsłudze, ale nie spełniał podstawowych wymogów. Jeśli znajomość wzorców projektowych utrudnia Ci podejmowanie racjonalnych decyzji, to ich stosowanie wyrządzi więcej krzywdy niż dobra.
Brzydkie Wzorce projektowe i Java EE to starzy dobrzy znajomi, choć przyjaźń ta miała lepsze i gorsze okresy. Gdy technologia J2EE zyskała uznanie w świecie biznesu i zaczęto jej używać do realizacji dużych projektów, wzorce projektowe były jak koło ratunkowe. W pisanych wówczas aplikacjach znalazły się implem entacje wielu klasycznych wzorców z książki Bandy Czworga. W krótce pojawiły się też wzorce rozwiązujące typowe problem y środowisk biznesowych na platformie J2EE. Technologia J2EE zyskała dużą popularność i przyczyniła się do rozpowszechnienia wielu koncepcji, takich jak np. Service Oriented Architecture (SOA) czy usługi sieciowe. Niestety, jej skom plikow ana struktura doprow adziła wiele projektów do upadku. Ziarna J2EE m usiały rozszerzać klasy i wymagały ciężkiego kontenera do działania. Ta zależność od kontenera wymuszała wykorzystywanie kompletnego serwera, co spowalniało prace i skłaniało do zakupu kosztownego sprzętu. Ale nawet po spełnieniu wszystkich warunków aplikacje biznesowe nadal
Brzydkie
| 229
były ociężałe, przez co odświeżanie i ich ponowne uruchamianie trwały o wiele za długo. Także prawidłowe przeprowadzenie testów graniczyło z cudem. Ponadto konfiguracja J2EE opierała się na plikach XML, przez co była ciężka. Choć rozdzielenie konfiguracji i kodu wydawało się dobrym pomysłem, szybko się okazało, że to ślepa uliczka. Do utworzenia nawet prostego ziarna trzeba było napisać mnóstwo kodu konfiguracyjnego. Gdy technologia J2EE zyskała status platform y biznesowej, konsultanci, architekci i dostawcy publikowali skomplikowane wytyczne, których przestrzeganie prowadziło do powstawania nadm iernie złożonych i przerośniętych aplikacji. Ich testowanie, rozwijanie, debugowanie i wdrażanie z powodu długiego czasu urucham iania graniczyło z niemożliwością. N a szczęście wszystko dobrze się skończyło. Rod Johnson8 stanął na czele inicjatywy zorganizowanej w celu zapewnienia lekkiego kontenera i możliwości używania zwykłych obiektów Javy. Inicjatywa ta zyskała ogrom ne poparcie i stała się poważnym konkurentem technologii J2EE. Tak powstał system Spring, który umożliwiał korzystanie z lekkiego kontenera i uruchamianie program ów na prostych serwerach Javy. Możliwość korzystania z obiektów POJO znacznie ułatwiała testowanie i pozwalała na pozbycie się kontenera w większości przypadków. Nawet jeśli kontener był potrzebny, to nietrudno się go obsługiwało. Powodzenie systemu Spring stało się bodźcem do unowocześnienia Javy. Java EE 5 była całkiem nową technologią z ziarnami w postaci zwykłych obiektów i lekkim kontenerem. Technologia przeszła ewolucję i dojrzała. Niestety, starych nawyków i technik program ow ania nie m ożna się pozbyć w jeden dzień. W ielu program istów do dziś stosuje dawne m etody programowania z czasów J2EE, tworząc niepotrzebnie złożone aplikacje i nie posługując się lekkimi konteneram i ani serwerami. Tak jak nasz język ojczysty zmienił się od czasów Kochanowskiego, platformy i języki programowania również przechodzą przemiany. Nie m a sensu kurczowo trzymać się przeszłości.
OPOWIADANIE WOJENNE Niedawno pojawiła się technologia J2EE 1.4 i mieliśmy za zadanie zaimplementować następną generację systemów bankowych. W naszej implementacji zastosowaliśmy najlepsze techniki, wzorce, wytyczne i ogólnie wszystko, co udało się nam znaleźć w książkach i internecie. Nasza aplikacja była w dużym stopniu zależna od jednego dostawcy i nie była przenośna. Musieliśmy używać narzuconego środowiska programistycznego i serwera, a były to czasy 32-bitowych systemów operacyjnych, w których Windows nie adresował więcej niż 3 GB pamięci RAM. W efekcie serwer i środowisko programistyczne działały tak wolno, że w trybie diagnostycznym nie musieliśmy nawet ustawiać punktów wstrzymania. Dostawca zapewniał nas jednak, że środowisko produkcyjne będzie znacznie szybsze. Ale to nie zmieniało faktu, że praca nad programem szła jak po grudzie. Podczas restartowania serwera mogliśmy spokojnie iść na kawę. Jeszcze ciekawiej było, gdy chcieliśmy przejść do środowiska produkcyjnego. Okazało się, że komputery są tak samo wolne jak w środowisku testowym. Szybko wyrobiliśmy sobie nawyk obserwowania statusu pamięci obu środowisk.
8 R od Jo h n so n — australijski p ro g ram ista, tw ó rca system u szkieletow ego Spring.
230
ROZDZIAŁ 16. Wzorce projektowe — dobre, złe i brzydkie
W końcu postanowiliśmy zatrudnić konsultanta, aby pokazał nam, co robiliśmy źle. Był to stary i bardzo mądry facet, którego traktowaliśmy jak wyrocznię. Przez kilka dni przeglądał nasz kod, a potem kazał pousuwać wszystkie fasady (mieliśmy fasadę prawie dla każdego ziarna) i niepotrzebne interfejsy (niewiele brakowało, a zaczęlibyśmy tworzyć interfejsy dla interfejsów). Dodatkowo kazał nam zmniejszyć liczbę warstw przez ograniczenie hierarchii (EJB wywołujące EJB wywołujące EJB...). To były czasy technologii J2EE, w których korzystało się z ciężkich serwerów od dostawców, więc nic wielkiego się nie stało. Ale udało się trochę zwiększyć wydajność i przynajmniej sprawić, że kod stał się bardziej czytelny. Zakładając, że wszystko może się zmienić, programowanie z myślą o elastyczności wcale nie stanowi gwarancji ułatwień jutro, a co najwyżej daje gwarancję problemów dziś.
Podsumowanie W zorce projektowe to jedna z najważniejszych, najbardziej wymagających i przydatnych dziedzin w program owaniu komputerowym. Nikt, kto ich nie zna, nie może nazwać się kompletnym program istą obiektowym. Dobra znajomość tych narzędzi stanowi wyposażenie, dzięki którem u jesteśmy w stanie efektywnie rozwiązać wiele typowych problemów. Twórcy Javy EE posunęli się nawet o krok dalej i wprowadzili wiele udogodnień ułatwiających implementowanie wielu wzorców w projektach biznesowych. Większość wzorców projektowych do Javy EE wprowadzono po długich i burzliwych dyskusjach, co stanowi gwarancję, że są to dobre i dojrzałe implementacje. Wszystkie opisane w tej książce wzorce spełniają wymogi standardów, więc m ożna powiedzieć, że prawie na pewno będą działały. Mimo to wzorców projektowych nie m ożna traktować jak panaceum ani magiczną różdżkę. Stosowane bez potrzeby mogą tylko przyczynić się do nadmiernego skomplikowania programu. To, że ktoś zna jakiś wzorzec, nie znaczy wcale, że m usi go używać. Decyzję o zastosowaniu wzorca zawsze należy podejm ować na podstawie analizy problemu. W arto poznać wzorce projektowe i nauczyć się je stosować. Dobrze jest też co jakiś czas odświeżyć sobie pamięć, aby nie zapomnieć, do czego służą. Dzięki tem u można zaoszczędzić dużo pracy i zyskać szacunek innych programistów.
Skorowidz
A
aspekty, 122 asynchroniczne
abstrakcyjny d ekorator, 107
serwlety, 140
adnotacja, 37
ziarna, 138
@ D ependsO n, 65
a synchroniczność, 133
@ G eneratedV alue, 176 @ Inject, 76, 79, 94
B
@ Interceptor, 124 @ Interceptors, 124
baza danych ty p u N oSQL, 171
@Lock, 67
bezpieczeństw o, 32
@ M essageEvent, 166 @ Nam ed, 76-80, 96, 207
bezstanow ość, 184
C
@ Observes, 166 @ Path, 193 @ Produce, 101
CDI, C ontext a n d D ependency Injection, 34, 43, 71, 77
@ RequestScope, 207 @ Schedule, 150, 156
CM P, C o n tain e r-M an a g e d Persistence, 174 cykl życia in te rce p to ra, 125
@Secure, 129
czasom ierz, 155
@ Tim eout, 151, 156
autom atyczny, 150
@ T ransient, 176
program ow y, 151
stereotypow a, 82
czas d o stę p u w spółbieżnego, 68
agencja inform acyjna, 162
D
alternatyw y, 81 antyw zorce, 35, 220 A O P, a sp ect-o rien ted p ro g ram m in g , 117
D A O , d ata access object, 172
A PI JPA, 174
definicja filtru serw letu, 121
arch itek tu ra
dekom pozycja n a usługi, 218
Lazani, 221
d e k o rato r
m ikrousługow a, 215, 219
B lackF ridayD iscountD ecorator, 111
m onolityczna, 215, 216, 220
dodający dodatki, 107
w ielow arstw ow a, 38
P riceD isco u n tD eco rato r, 110 d e k o rato ry bez k onfiguracji XM L, 113 dekorow anie, 109 delegacja, 143
2 3 2 I JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
D I, D ep en d en cy Injection, 71
czasom ierza program ow ego, 152
d iagram klas
czasom ierza w Javie EE, 150
dziedziczenie, 28
D A O , 179
w zorca
fabryki, 99
D ekorator, 105
Fabryki A bstrakcyjnej, 90
D o stęp u do D anych, 172
filtru serw letu, 121
Fabryka A bstrakcyjna, 90
in tercep to ra, 122
Fasady, 51
in te rce p to ró w klasow ych, 123
O bserw ator, 162
interfejsu A b stractD rinksM achineF actory, 91
Singleton, 59
interfejsu D A O , 177, 179
d iagram w zorca M odel - W id o k - K ontroler, 201
interfejsu U serD ataR epository, 73
długotrw ałe sondow anie, 212
LongM essage, 98
d o k u m e n t JSR, 41
M eto d y F abrycznej, 88, 91
dostęp w spółbieżny do singletonu, 68
publikacja-subskrypcja, 215
D T O , d ata tra n sfe r object, 172, 200
p u n k t do p u n k tu , 214 ra d y docelow ej, 123
E E JB ,78
REST w Javie EE, 191 REST-owego interfejsu A PI, 191 ShortM essage, 98
EJB, E n terp rise JavaBeans, 41
SoftD rinksM achine, 88
EL, 80
w strzykiw ania zależności, 72
encja, entity, 174
w strzykiw ania zależności w Javie EE, 75 w zorca
F
DA O w Javie EE, 174 D ekorator, 106
fabryka, 85
D e k o rato r w Javie EE, 109
A bstrakcyjna, 85, 89
Fabryka w Javie EE, 91
D A O , 177
Fasada, 52
facelety, 206
Fasada w Javie EE, 53
filtr serw letu, 120
M V C , 202, 206, 207
fo rm a t JSON, 191
M V C w Javie EE, 206 O bserw ator, 162
G
O b serw ato r w Javie EE, 164 Singleton, 59, 62
gniazda sieciowe, 212
S ingleton w Javie EE, 63
H
w zorców projektow ych, 47 inform acje o kontekście, 124
H A TEO A S, 182, 194
o w zo rcu D A O , 173
I idem potencja, 187 im p lem entacja @Secure, 129 A O P, 120
in te rce p to r, 44, 117, 122, 125 in te rc e p to r dziennika, 45 in te rce p to ry CD I, 128 n a po zio m ie dom yślnym , 125 interfejs
asynchroniczności, 136
A b stractD rinksM achineF actory, 91
autom atycznego czasom ierza, 151
API, 197
bezstanow ej fasady, 54
D A O , 176
C offeM achine, 88
dla fabryki abstrakcyjnej, 90
Skorowidz I 2 3 3
L
kw alifikacyjny adnotacji, 166 M essageType, 98 O bservable, 164
LDAP, L ightw eight D ire cto ry Access Protocol, 171
O rder, 106
literał adnotacyjny, 99
Pro d u ct, 109
M
Publisher, 163 Serializable, 176 T im er, 150
m apow anie obiektow o-relacyjne, ORM , 174
T im erService, 151, 152
m eto d a
U serD ataR epository, 73
DELETE, 188 GET, 187
J
executeT ask, 150 Fabryczna, 85, 86
J2EE, 31
GET, 194
Java SE, Java S ta n d ard E dition, 31
getInfo, 150
jed n o stk a u trw alania, 178
g etN extT im eout, 153
JPA, Java Persistence API, 174
g e tT hirdC hild, 168
JPE, 31
isC alendarT im er, 153
JSF, 80
PO ST, 188, 194
JSR, Java Specification R equest, 41
PU T, 188 serviceTrace, 165
K klasa akcji, 205
setR ollbackO nly, 169 setT im er, 151 startA sync(), 141 startService, 165
D rinksM achine, 88
m eto d y H T T P , 187
encyjna, 175
m ikrousługi, 219
fabryczna, 204
m odel
L istU serA ction, 206
dojrzałości R ichardsona, 185
O bservable, 164
k o m p o n en to w y , 42
U ser, 73 U serService, 73-76, 203 U serServiceFactory, 74 klient-serw er, 183
pro g ram o w an ia J2EE, 227 m odyfikow anie czasom ierza, 155 M V C, m odel-view -controller, 199 M V P, m odel, view, p resen ter, 202
kolejka, 214
N
kolejność intercep to ró w , 126 u ru c h am ia n ia, 65
nazew nictw o, 80
k o m p o n e n t sieciowy, 40
nazew nictw o zasobów , 186
konfiguracja serw letu facesservlet, 206
niejednoznaczność, 95
k onteksty, 44, 77, 79
n iesta n d ard o w a adnotacja w iadom ości, 99
k o n te n e r CD I, 97, 101
n iesta n d ard o w y typ adnotacji, 95
k o n tro ler, 200
O
konw encja, 43 kw alifikator, 81, 95 LongM essage, 94 n iestandardow y, 112 ShortM essage, 94
obiekt d o stę p u do danych, D A O , 172 D T O , 173 JSON, 192 tra n sfe ru danych, D T O , 172
2 3 4 I JAVA EE. ZAAWANSOWANE WZORCE PROJEKTOWE
obiekt
rozstrzyganie
ty p u M a nagedT hreadF actory, 142
niejednoznaczności, 95, 96
ty p u S cheduleE xpression, 153
w ieloznaczności, 77
obserw ator, observer, 160
rozw iązania dla biznesu, 31
R adioC hannel, 163
S
zdarzeń transakcji, 167 obserw ow alne ziarno usługow e, 164 od b io rn ik , listen er, 161
schem at im p lem en tacji M V C , 202
od m ierzan ie czasu, 147
serw er Java EE, 41
określanie kolejności u ru c h am ia n ia, 65, 66
serwlet, 140
operacje CRU D , 172
serw let FacesServlet, 206
ORM , O bject-R elational M apping, 174
skalow alność, 217 SOA, Service O rie n te d A rchitecture, 33, 215, 228
P
stereotypy, 82 synchronizacja singletonu, 60
p lik persistence.xm l, 178
system szkieletowy, 222
pliki EJB-JAR, 126
sześcian AKF, 217
p o b iera n ie inform acji, 124
T
podłączanie faz cyklu życia, 125 p o d m io t, 160 PO JO , 37
tech n ik a CD I, 77
profil sieciow y Javy EE, 42
technologia J2EE, 32
pro g ram o w an ie
tem aty, topics, 189, 214
aspektow e, A O P, 117
transakcje, 32, 156
asynchroniczne, 133, 138
tw orzenie
przekazyw anie w iadom ości, 214
o biektu singletonow ego, 60, 61
przen o śn o ść, 32
użytkow nika, 189
publikacja-subskrypcja, 215
typ wyliczeniow y, 62
punkt do p u n k tu , 214
typy w zorca M V C , 201
U
końcow y, 212 k ońcow y z adnotacjam i, 213 U berklasa, 220
R
users, 188 usługa o d m ierzan ia czasu, 147
re p o zy to riu m LDAP, 171
usługi sieciowe, 181
REST, 181, 182
użytkow nicy, users, 188
bezstanow ość, 184
używ anie
jed n o lity interfejs, 184
in tercep to ró w , 130
klien t-serw er, 183
p ro g ram o w a n ia asynchronicznego, 143
k o d n a żądanie, 184
REST, 196
nazew nictw o zasobów , 186
w zorca D A O , 180
posts, 189
w zorca D ekorator, 114
system w arstw ow y, 184
w zorca Fasada, 55
topics, 189
w zorca M V C , 208
users, 188
w zorca O bserw ator, 169
zapisyw anie danych w buforze, 184
w zorca Singleton, 69
REST-ow y interfejs API, 185, 188
w zorców , 227
ro z ró ż n ian ie ziaren, 96
w zorców fabrycznych, 100
Skorowidz I 2 3 5
W
w zorzec A synchroniczność, 134
w arstw a
D ekorator, 103
EIS, 40
D ostęp do D anych, 171, 172
kliencka, 39
Fabryka, 85
logiki biznesow ej, 40
Fasada, 49
p o śred n ia, 214
M odel - W id o k - K ontroler, 199
w a ru n k i REST, 183
M V C , 200
w iązanie in tercep to ra, 129
O biekt T ran sfe ru D anych, 173
w idok, 200
O bserw ator, 159
w id o k ren d eru jąc y dane, 208
projektow y, 28
w pisy, posts, 189
Singleton, 57
w spółbieżność, 67 w strzykiw anie
Z
łańcucha, 92 zależności, 44, 77
zakres, 79
zależności, D I, 71
zalety a rch ite k tu ry m ikrousługow ej, 218
ziaren, 94, 96
zarządzanie w spółbieżnością, 67
w yjątek IndexO utO fB ounds, 168
zasada H ollyw ood, 160
w ykorzystyw anie singletonów , 64
zasady Javy EE, 42
w ykryw anie ziaren, 79
zdarzenie transakcji, 167
w yłączanie in tercep to ró w , 128
ziarna
w yrażenia
asynchroniczne, 138
czasowe, 153
bezstanow e, 53
kalendarzow e, 154
CD I, 78, 80
w yw oływ anie singletonu, 64
obserw atora, 165
w zorce
singletonow e, 63
behaw ioralne, 30 biznesow e, 33
usługow e, 164
konstrukcyjne, 30
w iadom ości, 93
stru k tu raln e, 30 zw iązane z CD I, 82
stanow e, 55
w spierające, 206 ziarno, 38 encyjne, e n tity bean, 174 M essageA , 92 M essageB, 93
![Java [1] - walc musette](https://docer.tips/img/300x300/java-1-walc-musette_5a74391ed64ab2e712979505.jpg)
![Java [2] - walc musette](https://docer.tips/img/300x300/java-2-walc-musette_5a725bc4d64ab251b3c20799.jpg)
![[EYROLLES] Exercices en Java](https://docer.tips/img/300x300/eyrolles-exercices-en-java_5ad30b7e7f8b9a7e228b475c.jpg)
