Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00577 007397 13615023 na godz. na dobę w sumie
Spring w akcji. Wydanie IV - ebook/pdf
Spring w akcji. Wydanie IV - ebook/pdf
Autor: Liczba stron: 624
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-0852-7 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> java - programowanie
Porównaj ceny (książka, ebook (-20%), audiobook).

Kompendium wiedzy na temat Spring Framework!

Spring jest odpowiedzią na problemy trapiące programistów tworzących oprogramowanie przy użyciu EJB 2.x. Dzień, w którym został udostępniony szerokiemu gronu użytkowników, był punktem zwrotnym w historii języka Java. Od tej pory życie deweloperów stało się prostsze, a tworzenie nawet skomplikowanych aplikacji — zdecydowanie przyjemniejsze. Od tamtego czasu Spring jest wciąż rozwijany i oferuje coraz lepsze narzędzia programistom na całym świecie.

Kolejne wydanie tej książki, w całości poświęconej frameworkowi Spring (w wersji 4), zostało poprawione, zaktualizowane i uzupełnione o nowe informacje. W trakcie lektury przekonasz się, jakie nowości zostały wprowadzone w czwartej wersji Springa, oraz zaznajomisz się z zaawansowanymi metodami wiązania komponentów. Ponadto zdobędziesz doświadczenie w stosowaniu aspektów, zobaczysz, jak działają Spring MVC czy Spring WebFlow, oraz nauczysz się uzyskiwać dostęp do baz danych — zarówno SQL, jak i NoSQL. Osobny rozdział został poświęcony bezpieczeństwu aplikacji tworzonych z wykorzystaniem Springa. Spring Security to potężne narzędzie, które pozwoli Ci bezboleśnie wprowadzić zaawansowane mechanizmy bezpieczeństwa w Twoich programach. Na sam koniec poznasz techniki obsługi komunikatów oraz możliwości modułu Spring Boot. Książka ta jest doskonałą lekturą dla programistów chcących w pełni wykorzystać potencjał Springa!

Dzięki tej książce:

Niemal 100 tysięcy programistów sięgnęło po tę książkę, by nauczyć się Springa! Jej lektura wymaga praktycznej znajomości języka Java. Poznaj potencjał Springa! 

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Spring in Action, Fourth Edition Tłumaczenie: Mirosław Gołda (wstęp, rozdz. 1 – 14), Piotr Rajca (rozdz. 15 – 21) ISBN: 978-83-283-0849-7 Original edition copyright © 2015 by Manning Publications Co. All rights reserved. Polish edition copyright © 2015 by HELION SA. All rights reserved. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Projekt okładki: Studio Gravite / Olsztyn; Obarek, Pokoński, Pazdrijowski, Zaprucki Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/sprwa4 Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis tre(cid:258)ci Przedmowa 13 Podzi(cid:218)kowania 15 O ksi(cid:200)(cid:285)ce 17 CZ(cid:125)(cid:165)(cid:109) I. PODSTAWY FRAMEWORKA SPRING 21 Rozdzia(cid:239) 1. Zrywamy si(cid:218) do dzia(cid:239)ania 23 1.1. Upraszczamy programowanie w Javie 24 1.1.1. Uwalniamy moc zawart(cid:200) w POJO 25 1.1.2. Wstrzykujemy zale(cid:285)no(cid:258)ci 25 1.1.3. 1.1.4. Ograniczamy powtórzenia kodu dzi(cid:218)ki szablonom 36 Stosujemy aspekty 31 1.2. Kontener dla naszych komponentów 38 1.3. Pracujemy z kontekstem aplikacji 39 1.2.1. 1.2.2. Cykl (cid:285)ycia komponentu 40 Podziwiamy krajobraz Springa 42 1.3.1. Modu(cid:239)y Springa 42 1.3.2. Rodzina projektów wokó(cid:239) Springa 45 1.4. Co nowego w Springu 48 1.4.1. Co nowego w Springu 3.1? 49 1.4.2. Co nowego w Springu 3.2? 50 1.4.3. Co nowego w Springu 4.0? 51 Podsumowanie 52 1.5. Rozdzia(cid:239) 2. Tworzymy powi(cid:200)zania mi(cid:218)dzy komponentami 53 Poznajemy opcje konfiguracji Springa 54 2.1. 2.2. Wykorzystujemy automatyczne wi(cid:200)zanie komponentów 55 Tworzymy wyszukiwalne komponenty 56 2.2.1. 2.2.2. Nadajemy nazwy skanowanemu komponentowi 59 2.2.3. Ustawiamy pakiet bazowy dla skanowania komponentów 60 2.2.4. Oznaczamy adnotacj(cid:200) komponenty przeznaczone do autowi(cid:200)zania 61 2.2.5. Weryfikujemy automatyczn(cid:200) konfiguracj(cid:218) 63 2.3. Wi(cid:200)(cid:285)emy kod za pomoc(cid:200) Javy 64 Tworzymy klasy konfiguracji 64 2.3.1. 2.3.2. Deklarujemy prosty komponent 65 2.3.3. Wstrzykujemy zale(cid:285)no(cid:258)ci za pomoc(cid:200) konfiguracji JavaConfig 66 Poleć książkęKup książkę 6 Spis tre(cid:258)ci 2.4. Wi(cid:200)(cid:285)emy komponenty za pomoc(cid:200) plików XML 68 Tworzymy specyfikacj(cid:218) konfiguracji XML 68 2.4.1. 2.4.2. Deklarujemy prosty komponent 69 2.4.3. Wstrzykujemy komponent przez konstruktor 70 2.4.4. Ustawiamy w(cid:239)a(cid:258)ciwo(cid:258)ci 76 Importujemy i (cid:239)(cid:200)czymy konfiguracje 81 2.5.1. Odwo(cid:239)ujemy si(cid:218) do konfiguracji XML z poziomu konfiguracji JavaConfig 82 2.5.2. Odwo(cid:239)ujemy si(cid:218) do konfiguracji JavaConfig z poziomu konfiguracji XML 83 Podsumowanie 85 2.5. 2.6. Rozdzia(cid:239) 3. Zaawansowane opcje wi(cid:200)zania 87 3.1. (cid:165)rodowiska i profile 87 3.1.1. Konfigurujemy komponenty profilu 89 3.1.2. Aktywujemy profil 93 3.2. Warunkowe komponenty 95 3.3. Radzimy sobie z niejednoznaczno(cid:258)ciami w autowi(cid:200)zaniach 98 3.3.1. Wybieramy g(cid:239)ówny komponent 99 3.3.2. Kwalifikujemy autowi(cid:200)zane komponenty 100 3.4. Ustalamy zasi(cid:218)g komponentów 104 Zasi(cid:218)g (cid:285)(cid:200)dania oraz sesji 105 3.4.1. 3.4.2. Deklarujemy obiekty po(cid:258)rednicz(cid:200)ce o okre(cid:258)lonym zasi(cid:218)gu za pomoc(cid:200) XML 107 3.5. Wstrzykujemy warto(cid:258)ci w czasie wykonywania 108 3.5.1. Wstrzykujemy zewn(cid:218)trzne warto(cid:258)ci 109 3.5.2. Podsumowanie 119 Tworzymy powi(cid:200)zania z u(cid:285)yciem j(cid:218)zyka wyra(cid:285)e(cid:241) Springa (SpEL) 113 3.6. Rozdzia(cid:239) 4. Aspektowy Spring 121 4.1. Czym jest programowanie aspektowe 122 4.1.1. Definiujemy terminologi(cid:218) dotycz(cid:200)c(cid:200) AOP 123 4.1.2. Obs(cid:239)uga programowania aspektowego w Springu 126 4.2. Wybieramy punkty z(cid:239)(cid:200)czenia za pomoc(cid:200) punktów przeci(cid:218)cia 128 Piszemy definicje punktów przeci(cid:218)cia 130 4.2.1. 4.2.2. Wybieramy komponenty w punktach przeci(cid:218)cia 131 4.3. Tworzenie aspektów z u(cid:285)yciem adnotacji 131 4.3.1. Definiujemy aspekt 131 Tworzymy porady around 136 4.3.2. 4.3.3. Przekazujemy parametry do porady 137 4.3.4. Wprowadzenia z u(cid:285)yciem adnotacji 140 4.4. Deklarujemy aspekty w j(cid:218)zyku XML 143 4.4.1. Deklarujemy porady before i after 144 4.4.2. Deklarujemy porad(cid:218) around 146 4.4.3. 4.4.4. Wprowadzamy now(cid:200) funkcjonalno(cid:258)(cid:202) przez aspekty 150 Przekazujemy parametry do porady 148 4.5. Wstrzykujemy aspekty z AspectJ 151 4.6. Podsumowanie 153 Poleć książkęKup książkę Spis tre(cid:258)ci 7 CZ(cid:125)(cid:165)(cid:109) II. SPRING W SIECI 155 Rozdzia(cid:239) 5. Budowanie aplikacji internetowych za pomoc(cid:200) Springa 157 5.1. Wprowadzenie do Spring MVC 158 5.1.1. Cykl (cid:285)ycia (cid:285)(cid:200)dania 158 5.1.2. Konfiguracja Spring MVC 160 5.1.3. Wprowadzenie do aplikacji Spittr 165 5.2. Tworzymy prosty kontroler 165 Testujemy kontroler 167 5.2.1. 5.2.2. Definiujemy obs(cid:239)ug(cid:218) (cid:285)(cid:200)da(cid:241) na poziomie klasy 169 5.2.3. Przekazujemy dane modelu do widoku 170 5.3. Obs(cid:239)ugujemy dane wej(cid:258)ciowe 175 Pobieramy parametry zapytania 176 Pobieramy dane wej(cid:258)ciowe za po(cid:258)rednictwem parametrów (cid:258)cie(cid:285)ki 178 5.3.1. 5.3.2. Przetwarzamy formularze 180 5.4.1. 5.4.2. Walidujemy formularze 186 Podsumowanie 189 5.4. 5.5. Tworzymy kontroler do obs(cid:239)ugi formularza 182 Rozdzia(cid:239) 6. Generowanie widoków 191 Poznajemy sposób produkowania widoków 191 6.1. 6.2. Tworzymy widoki JSP 194 6.2.1. Konfigurujemy producenta widoków gotowego do pracy z JSP 194 6.2.2. Korzystamy z bibliotek JSP Springa 196 6.3. Definiujemy uk(cid:239)ad stron za pomoc(cid:200) widoków Apache Tiles 209 6.3.1. Konfigurujemy producenta widoków Tiles 209 Pracujemy z Thymeleaf 214 6.4.1. Konfigurujemy producenta widoków Thymeleaf 215 6.4.2. Definiujemy szablony Thymeleaf 216 Podsumowanie 220 6.4. 6.5. Rozdzia(cid:239) 7. Zaawansowane mo(cid:285)liwo(cid:258)ci Spring MVC 221 7.1. Alternatywna konfiguracja Spring MVC 222 7.1.1. Dostosowujemy konfiguracj(cid:218) serwletu dystrybutora 222 7.1.2. Dodajemy kolejne serwlety i filtry 223 7.1.3. Deklarujemy serwlet dystrybutora za pomoc(cid:200) pliku web.xml 225 Przetwarzamy dane formularza wielocz(cid:218)(cid:258)ciowego 227 7.2.1. Konfigurujemy rezolwer danych wielocz(cid:218)(cid:258)ciowych 228 7.2.2. Obs(cid:239)ugujemy (cid:285)(cid:200)dania wielocz(cid:218)(cid:258)ciowe 232 7.2. 7.3. Obs(cid:239)ugujemy wyj(cid:200)tki 236 7.3.1. Mapujemy wyj(cid:200)tki na kody odpowiedzi HTTP 236 7.3.2. Tworzymy metody obs(cid:239)ugi wyj(cid:200)tków 238 7.4. Doradzamy kontrolerom 239 7.5. Przenosimy dane mi(cid:218)dzy przekierowaniami 240 7.5.1. Wykonujemy przekierowanie z u(cid:285)yciem szablonów URL 241 7.5.2. Podsumowanie 244 Pracujemy z atrybutami jednorazowymi 242 7.6. Poleć książkęKup książkę 8 Spis tre(cid:258)ci Rozdzia(cid:239) 8. Praca ze Spring Web Flow 247 8.1. Konfiguracja Spring Web Flow 248 8.1.1. Dowi(cid:200)zanie egzekutora przep(cid:239)ywu 248 8.1.2. Konfiguracja rejestru przep(cid:239)ywów 249 8.1.3. Obs(cid:239)uga (cid:285)(cid:200)da(cid:241) przep(cid:239)ywu 250 8.2. Sk(cid:239)adowe przep(cid:239)ywu 250 Stany 251 Przej(cid:258)cia 254 8.2.1. 8.2.2. 8.2.3. Dane przep(cid:239)ywu 255 8.3. (cid:146)(cid:200)czymy wszystko w ca(cid:239)o(cid:258)(cid:202): zamówienie pizzy 257 Zbieranie informacji o kliencie 261 8.3.1. Definiowanie bazowego przep(cid:239)ywu 257 8.3.2. 8.3.3. Budowa zamówienia 266 8.3.4. Przyjmowanie p(cid:239)atno(cid:258)ci 269 8.4. Zabezpieczanie przep(cid:239)ywu 271 8.5. Podsumowanie 271 Rozdzia(cid:239) 9. Zabezpieczanie Springa 273 9.1. Rozpoczynamy prac(cid:218) ze Spring Security 274 9.1.1. 9.1.2. 9.1.3. Poznajemy modu(cid:239)y Spring Security 274 Filtrujemy (cid:285)(cid:200)dania internetowe 275 Tworzymy prost(cid:200) konfiguracj(cid:218) bezpiecze(cid:241)stwa 276 9.2. Wybieramy us(cid:239)ugi szczegó(cid:239)ów u(cid:285)ytkownika 279 Tworzymy w(cid:239)asn(cid:200) us(cid:239)ug(cid:218) u(cid:285)ytkowników 287 Pracujemy z baz(cid:200) u(cid:285)ytkowników zapisan(cid:200) w pami(cid:218)ci 279 9.2.1. 9.2.2. Uwierzytelnianie w oparciu o tabele danych 281 9.2.3. Uwierzytelniamy u(cid:285)ytkownika w oparciu o us(cid:239)ug(cid:218) LDAP 283 9.2.4. Przechwytywanie (cid:285)(cid:200)da(cid:241) 289 9.3.1. 9.3.2. Wymuszamy bezpiecze(cid:241)stwo kana(cid:239)u komunikacji 292 9.3.3. Ochrona przed atakami CSRF 294 Zabezpieczanie za pomoc(cid:200) wyra(cid:285)e(cid:241) Springa 291 9.3. 9.4. Uwierzytelnianie u(cid:285)ytkowników 295 9.4.1. Dodajemy w(cid:239)asn(cid:200) stron(cid:218) logowania 296 9.4.2. W(cid:239)(cid:200)czamy uwierzytelnianie HTTP Basic 297 9.4.3. W(cid:239)(cid:200)czenie funkcji „pami(cid:218)taj mnie” 298 9.4.4. Wylogowujemy si(cid:218) 299 Zabezpieczanie elementów na poziomie widoku 300 9.5.1. Korzystamy z biblioteki znaczników JSP w Spring Security 300 9.5.2. Podsumowanie 305 Pracujemy z dialektem Spring Security w Thymeleaf 304 9.5. 9.6. CZ(cid:125)(cid:165)(cid:109) III. SPRING PO STRONIE SERWERA 307 Rozdzia(cid:239) 10. Korzystanie z bazy danych z u(cid:285)yciem Springa i JDBC 309 10.1. Filozofia dost(cid:218)pu do danych Springa 310 10.1.1. Hierarchia wyj(cid:200)tków zwi(cid:200)zanych z dost(cid:218)pem do danych w Springu 311 10.1.2. Szablony dost(cid:218)pu do danych 314 Poleć książkęKup książkę Spis tre(cid:258)ci 9 10.2. Konfiguracja (cid:283)ród(cid:239)a danych 316 10.2.1. (cid:189)ród(cid:239)a danych JNDI 316 10.2.2. (cid:189)ród(cid:239)a danych z pul(cid:200) 317 10.2.3. (cid:189)ród(cid:239)a danych oparte na sterowniku JDBC 318 10.2.4. Korzystamy z wbudowanego (cid:283)ród(cid:239)a danych 320 10.2.5. Korzystamy z profili do wyboru (cid:283)ród(cid:239)a danych 321 10.3. U(cid:285)ywanie JDBC w Springu 323 10.3.1. Kod JDBC a obs(cid:239)uga wyj(cid:200)tków 323 10.3.2. Praca z szablonami JDBC 327 10.4. Podsumowanie 332 Rozdzia(cid:239) 11. Zapisywanie danych z u(cid:285)yciem mechanizmów ORM 333 11.1. Integrujemy Hibernate ze Springiem 335 11.1.1. Deklarowanie fabryki sesji Hibernate 335 11.1.2. Hibernate bez Springa 337 11.2. Spring i Java Persistence API 339 11.2.1. Konfiguracja fabryki mened(cid:285)erów encji 339 11.2.2. Klasa repozytorium na bazie JPA 344 11.3. Automatyczne repozytoria z wykorzystaniem Spring Data 346 11.3.1. Definiujemy metody zapyta(cid:241) 348 11.3.2. Deklarujemy w(cid:239)asne zapytania 351 11.3.3. Dodajemy w(cid:239)asne funkcjonalno(cid:258)ci 352 11.4. Podsumowanie 354 Rozdzia(cid:239) 12. Pracujemy z bazami NoSQL 357 12.1. Zapisujemy dane w MongoDB 358 12.1.1. W(cid:239)(cid:200)czamy MongoDB 359 12.1.2. Dodajemy adnotacje umo(cid:285)liwiaj(cid:200)ce zapis w MongoDB 362 12.1.3. Dost(cid:218)p do bazy MongoDB za pomoc(cid:200) szablonów MongoTemplate 365 12.1.4. Tworzymy repozytorium MongoDB 366 12.2. Pracujemy z danymi w postaci grafów w Neo4j 371 12.2.1. Konfigurujemy Spring Data Neo4j 371 12.2.2. Dodajemy adnotacje do encji grafów 374 12.2.3. Pracujemy z Neo4jTemplate 377 12.2.4. Tworzymy automatyczne repozytoria Neo4j 379 12.3. Pracujemy z danymi typu klucz-warto(cid:258)(cid:202) z u(cid:285)yciem bazy Redis 383 12.3.1. (cid:146)(cid:200)czymy si(cid:218) z Redisem 383 12.3.2. Pracujemy z klas(cid:200) RedisTemplate 385 12.3.3. Ustawiamy serializatory kluczy i warto(cid:258)ci 388 12.4. Podsumowanie 389 Rozdzia(cid:239) 13. Cachowanie danych 391 13.1. W(cid:239)(cid:200)czamy obs(cid:239)ug(cid:218) cachowania 392 13.1.1. Konfigurujemy mened(cid:285)era pami(cid:218)ci podr(cid:218)cznej 393 13.2. Stosowanie adnotacji cachowania na poziomie metod 397 13.2.1. Zapisujemy dane w pami(cid:218)ci podr(cid:218)cznej 398 13.2.2. Usuwamy wpisy z pami(cid:218)ci podr(cid:218)cznej 402 Poleć książkęKup książkę 10 Spis tre(cid:258)ci 13.3. Deklarujemy cachowanie w pliku XML 403 13.4. Podsumowanie 407 Rozdzia(cid:239) 14. Zabezpieczanie metod 409 14.1. Zabezpieczamy metody za pomoc(cid:200) adnotacji 410 14.1.1. Zabezpieczamy metody za pomoc(cid:200) adnotacji @Secured 410 14.1.2. Adnotacja @RolesAllowed ze specyfikacji JSR-250 w Spring Security 412 14.2. Korzystamy z wyra(cid:285)e(cid:241) do zabezpieczania metod 412 14.2.1. Wyra(cid:285)enia regu(cid:239) dost(cid:218)pu do metod 413 14.2.2. Filtrowanie danych wej(cid:258)ciowych i wyj(cid:258)ciowych metody 415 14.3. Podsumowanie 420 CZ(cid:125)(cid:165)(cid:109) IV. INTEGRACJA W SPRINGU 421 Rozdzia(cid:239) 15. Praca ze zdalnymi us(cid:239)ugami 423 15.1. Zdalny dost(cid:218)p w Springu 424 15.2. Praca z RMI 426 15.2.1. Eksportowanie us(cid:239)ugi RMI 427 15.2.2. Dowi(cid:200)zanie us(cid:239)ugi RMI 429 15.3. Udost(cid:218)pnianie zdalnych us(cid:239)ug za pomoc(cid:200) Hessian i Burlap 431 15.3.1. Udost(cid:218)pnianie funkcjonalno(cid:258)ci komponentu za pomoc(cid:200) Hessian/Burlap 432 15.3.2. Dost(cid:218)p do us(cid:239)ug Hessian/Burlap 435 15.4. Obiekt HttpInvoker 436 15.4.1. Udost(cid:218)pnianie komponentów jako us(cid:239)ug HTTP 437 15.4.2. Dost(cid:218)p do us(cid:239)ug przez HTTP 438 15.5. Publikacja i konsumpcja us(cid:239)ug sieciowych 439 15.5.1. Tworzenie punktów ko(cid:241)cowych JAX-WS w Springu 440 15.5.2. Po(cid:258)rednik us(cid:239)ug JAX-WS po stronie klienta 443 15.6. Podsumowanie 445 Rozdzia(cid:239) 16. Tworzenie API modelu REST przy u(cid:285)yciu Spring MVC 447 16.1. Zrozumienie REST 448 16.1.1. Fundamenty REST 448 16.1.2. Obs(cid:239)uga REST w Springu 449 16.2. Tworzenie pierwszego punktu ko(cid:241)cowego REST 450 16.2.1. Negocjowanie reprezentacji zasobu 452 16.2.2. Stosowanie konwerterów komunikatów HTTP 458 16.3. Zwracanie zasobów to nie wszystko 464 16.3.1. Przekazywanie b(cid:239)(cid:218)dów 464 16.3.2. Ustawianie nag(cid:239)ówków odpowiedzi 469 16.4. Konsumowanie zasobów REST 471 16.4.1. Operacje szablonu RestTemplate 472 16.4.2. Pobieranie zasobów za pomoc(cid:200) GET 473 16.4.3. Pobieranie zasobów 474 16.4.4. Odczyt metadanych z odpowiedzi 475 16.4.5. Umieszczanie zasobów na serwerze za pomoc(cid:200) PUT 476 16.4.6. Usuwanie zasobów za pomoc(cid:200) DELETE 478 Poleć książkęKup książkę Spis tre(cid:258)ci 11 16.4.7. Wysy(cid:239)anie danych zasobu za pomoc(cid:200) POST 478 16.4.8. Odbieranie obiektów odpowiedzi z (cid:285)(cid:200)da(cid:241) POST 478 16.4.9. Pobranie informacji o lokalizacji po (cid:285)(cid:200)daniu POST 480 16.4.10. Wymiana zasobów 481 16.5. Podsumowanie 483 Rozdzia(cid:239) 17. Obs(cid:239)uga komunikatów w Springu 485 17.1. Krótkie wprowadzenie do asynchronicznej wymiany komunikatów 486 17.1.1. Wysy(cid:239)anie komunikatów 487 17.1.2. Szacowanie korzy(cid:258)ci zwi(cid:200)zanych ze stosowaniem asynchronicznej wymiany komunikatów 489 17.2. Wysy(cid:239)anie komunikatów przy u(cid:285)yciu JMS 491 17.2.1. Konfiguracja brokera komunikatów w Springu 491 17.2.2. Szablon JMS Springa 494 17.2.3. Tworzenie obiektów POJO sterowanych komunikatami 502 17.2.4. U(cid:285)ywanie RPC opartego na komunikatach 505 17.3. Obs(cid:239)uga komunikatów przy u(cid:285)yciu AMQP 508 17.3.1. Krótkie wprowadzenie do AMQP 509 17.3.2. Konfigurowanie Springa do wymiany komunikatów przy u(cid:285)yciu AMQP 510 17.3.3. Wysy(cid:239)anie komunikatów przy u(cid:285)yciu RabbitTemplate 513 17.3.4. Odbieranie komunikatów AMQP 515 17.4. Podsumowanie 518 Rozdzia(cid:239) 18. Obs(cid:239)uga komunikatów przy u(cid:285)yciu WebSocket i STOMP 519 18.1. Korzystanie z API WebSocket niskiego poziomu 520 18.2. Rozwi(cid:200)zanie problemu braku obs(cid:239)ugi WebSocket 525 18.3. Wymiana komunikatów z u(cid:285)yciem STOMP 528 18.3.1. W(cid:239)(cid:200)czanie obs(cid:239)ugi komunikatów STOMP 530 18.3.2. Obs(cid:239)uga komunikatów STOMP nadsy(cid:239)anych przez klienty 533 18.3.3. Wysy(cid:239)anie komunikatów do klienta 537 18.4. Komunikaty skierowane do konkretnego klienta 541 18.4.1. Obs(cid:239)uga komunikatów skojarzonych z u(cid:285)ytkownikiem w kontrolerze 541 18.4.2. Wysy(cid:239)anie komunikatów do konkretnego u(cid:285)ytkownika 544 18.5. Obs(cid:239)uga wyj(cid:200)tków komunikatów 545 18.6. Podsumowanie 546 Rozdzia(cid:239) 19. Wysy(cid:239)anie poczty elektronicznej w Springu 547 19.1. Konfigurowanie Springa do wysy(cid:239)ania wiadomo(cid:258)ci e-mail 548 19.1.1. Konfigurowanie komponentu wysy(cid:239)aj(cid:200)cego 548 19.1.2. Dowi(cid:200)zanie komponentu wysy(cid:239)aj(cid:200)cego poczt(cid:218) do komponentu us(cid:239)ugi 550 19.2. Tworzenie e-maili z za(cid:239)(cid:200)cznikami 551 19.2.1. Dodawanie za(cid:239)(cid:200)czników 551 19.2.2. Wysy(cid:239)anie wiadomo(cid:258)ci e-mail z bogat(cid:200) zawarto(cid:258)ci(cid:200) 552 19.3. Tworzenie wiadomo(cid:258)ci e-mail przy u(cid:285)yciu szablonów 554 19.3.1. Tworzenie wiadomo(cid:258)ci e-mail przy u(cid:285)yciu Velocity 554 19.3.2. Stosowanie Thymeleaf do tworzenia wiadomo(cid:258)ci e-mail 556 19.4. Podsumowanie 558 Poleć książkęKup książkę 12 Spis tre(cid:258)ci Rozdzia(cid:239) 20. Zarz(cid:200)dzanie komponentami Springa za pomoc(cid:200) JMX 561 20.1. Eksportowanie komponentów Springa w formie MBean 562 20.1.1. Udost(cid:218)pnianie metod na podstawie nazwy 565 20.1.2. U(cid:285)ycie interfejsów do definicji operacji i atrybutów komponentu zarz(cid:200)dzanego 567 20.1.3. Praca z komponentami MBean sterowanymi adnotacjami 568 20.1.4. Post(cid:218)powanie przy konfliktach nazw komponentów zarz(cid:200)dzanych 570 20.2. Zdalny dost(cid:218)p do komponentów zarz(cid:200)dzanych 571 20.2.1. Udost(cid:218)pnianie zdalnych komponentów MBean 571 20.2.2. Dost(cid:218)p do zdalnego komponentu MBean 572 20.2.3. Obiekty po(cid:258)rednicz(cid:200)ce komponentów zarz(cid:200)dzanych 573 20.3. Obs(cid:239)uga powiadomie(cid:241) 575 20.3.1. Odbieranie powiadomie(cid:241) 576 20.4. Podsumowanie 577 Rozdzia(cid:239) 21. Upraszczanie tworzenia aplikacji przy u(cid:285)yciu Spring Boot 579 21.1. Prezentacja Spring Boot 580 21.1.1. Dodawanie zale(cid:285)no(cid:258)ci pocz(cid:200)tkowych 581 21.1.2. Automatyczna konfiguracja 584 21.1.3. Spring Boot CLI 585 21.1.4. Aktuator 586 21.2. Pisanie aplikacji korzystaj(cid:200)cej ze Spring Boot 586 21.2.1. Obs(cid:239)uga (cid:285)(cid:200)da(cid:241) 589 21.2.2. Tworzenie widoku 591 21.2.3. Dodawanie statycznych artefaktów 593 21.2.4. Trwa(cid:239)e zapisywanie danych 594 21.2.5. Próba aplikacji 596 21.3. Stosowanie Groovy i Spring Boot CLI 599 21.3.1. Pisanie kontrolera w j(cid:218)zyku Groovy 600 21.3.2. Zapewnianie trwa(cid:239)o(cid:258)ci danych przy u(cid:285)yciu repozytorium Groovy 603 21.3.3. Uruchamianie Spring Boot CLI 604 21.4. Pozyskiwanie informacji o aplikacji z u(cid:285)yciem aktuatora 605 21.5. Podsumowanie 609 Skorowidz 611 Poleć książkęKup książkę Obs(cid:239)uga komunikatów w Springu W tym rozdziale omówimy: (cid:81) Wprowadzenie do asynchronicznej wymiany komunikatów (cid:81) Wymian(cid:266) komunikatów przy u(cid:298)yciu JMS (cid:81) Wysy(cid:225)anie komunikatów przy u(cid:298)yciu Springa i AMQP (cid:81) Obiekty POJO sterowane komunikatami Jest pi(cid:200)tek, godzina 16:55. Ju(cid:285) tylko minuty dziel(cid:200) Ci(cid:218) od d(cid:239)ugo oczekiwanego urlopu. Masz akurat tyle czasu, ile potrzeba, aby dojecha(cid:202) na lotnisko i wsi(cid:200)(cid:258)(cid:202) do samolotu. Zanim si(cid:218) jednak spakujesz i wyruszysz, musisz mie(cid:202) pewno(cid:258)(cid:202), (cid:285)e Twój szef i koledzy wiedz(cid:200), na jakim etapie jest projekt, aby bez problemu mogli kontynuowa(cid:202) prac(cid:218) nad nim w poniedzia(cid:239)ek. Niestety, cz(cid:218)(cid:258)(cid:202) kolegów urwa(cid:239)a si(cid:218) przed weekendem wcze(cid:258)nie, a szef jest na spotkaniu. Co robisz? Mo(cid:285)esz do szefa zadzwoni(cid:202), ale nie ma sensu przerywa(cid:202) spotkania z powodu zwy- k(cid:239)ego raportu o stanie projektu. Mo(cid:285)esz te(cid:285) spróbowa(cid:202) poczeka(cid:202), a(cid:285) spotkanie si(cid:218) sko(cid:241)czy, nikt jednak nie wie, ile potrwa, a samolot z pewno(cid:258)ci(cid:200) nie b(cid:218)dzie czeka(cid:239). A mo(cid:285)e przy- klei(cid:202) mu karteczk(cid:218) do monitora? Tu(cid:285) obok 100 innych, które ju(cid:285) tam s(cid:200)… Okazuje si(cid:218), (cid:285)e najpraktyczniejszym sposobem na poinformowanie szefa o stanie pracy i niespó(cid:283)nienie si(cid:218) przy tym na samolot b(cid:218)dzie krótka wiadomo(cid:258)ci e-mail do szefa i kolegów, zawieraj(cid:200)ca opis post(cid:218)pów i obietnic(cid:218) przys(cid:239)ania kartki z wakacji. Nie wiesz, gdzie si(cid:218) teraz znajduj(cid:200) ani kiedy przeczytaj(cid:200) wiadomo(cid:258)(cid:202), ale masz pewno(cid:258)(cid:202), (cid:285)e pr(cid:218)dzej czy pó(cid:283)niej usi(cid:200)d(cid:200) przy biurku i to zrobi(cid:200). Tymczasem Ty jeste(cid:258) ju(cid:285) w drodze na lotnisko. Poleć książkęKup książkę 486 ROZDZIA(cid:224) 17. Obs(cid:239)uga komunikatów w Springu Niektóre sytuacje wymagaj(cid:200) kontaktu bezpo(cid:258)redniego. Je(cid:285)eli zrobisz sobie krzywd(cid:218), do wezwania karetki u(cid:285)yjesz najprawdopodobniej telefonu — raczej nie b(cid:218)dziesz kontaktowa(cid:202) si(cid:218) ze szpitalem za pomoc(cid:200) poczty elektronicznej. Cz(cid:218)sto jednak wystar- czy wys(cid:239)anie wiadomo(cid:258)ci. Ta forma komunikacji ma nawet kilka dodatkowych zalet. Mo(cid:285)esz na przyk(cid:239)ad cieszy(cid:202) si(cid:218) wakacjami ju(cid:285) od samego pocz(cid:200)tku weekendu. Kilka rozdzia(cid:239)ów temu pokazali(cid:258)my, jak dzi(cid:218)ki RMI, Hessian, Burlap, obiektowi wywo(cid:239)uj(cid:200)cemu HTTP i us(cid:239)ugom sieciowym mo(cid:285)emy umo(cid:285)liwi(cid:202) komunikacj(cid:218) mi(cid:218)dzy aplikacjami. Ka(cid:285)dy z tych mechanizmów opiera si(cid:218) na synchronicznej komunikacji, w której aplikacja kliencka kontaktuje si(cid:218) ze zdaln(cid:200) us(cid:239)ug(cid:200) bezpo(cid:258)rednio i oczekuje na zako(cid:241)czenie zdalnej procedury przed kontynuacj(cid:200). Komunikacja synchroniczna ma wiele zastosowa(cid:241), ale nie jest bynajmniej jedynym stylem komunikacji mi(cid:218)dzy aplikacjami dost(cid:218)pnym dla programistów. Asynchroniczna obs(cid:239)uga komunikatów jest podej(cid:258)ciem pozwalaj(cid:200)cym na po(cid:258)rednie wysy(cid:239)anie komu- nikatów z jednej aplikacji do drugiej, bez potrzeby czekania na odpowied(cid:283). Rozwi(cid:200)zanie to ma w niektórych sytuacjach przewag(cid:218) nad komunikatami przesy(cid:239)anymi synchro- nicznie, o czym ju(cid:285) wkrótce si(cid:218) przekonamy. Spring udost(cid:218)pnia kilka sposobów asynchronicznej wymiany komunikatów. W tym rozdziale przyjrzymy si(cid:218), jak mo(cid:285)na wysy(cid:239)a(cid:202) i odbiera(cid:202) komunikaty w Springu, wykorzy- stuj(cid:200)c Java Message Service (JMS) oraz protokó(cid:239) AMQP (Advanced Message Queuing Protocol). Oprócz zwyk(cid:239)ego wysy(cid:239)ania i odbierania komunikatów omówimy równie(cid:285) obs(cid:239)ug(cid:218) przez Springa obiektów POJO sterowanych komunikatami, prostego sposobu odbierania komunikatów, który przypomina komponenty MDB (ang. message-driven beans) technologii EJB. 17.1. Krótkie wprowadzenie do asynchronicznej wymiany komunikatów Podobnie jak w przypadku mechanizmów zdalnego dost(cid:218)pu i interfejsów REST, któ- rymi zajmowali(cid:258)my si(cid:218) wcze(cid:258)niej w tej cz(cid:218)(cid:258)ci ksi(cid:200)(cid:285)ki, asynchroniczna wymiana komuni- katów s(cid:239)u(cid:285)y do nawi(cid:200)zywania komunikacji pomi(cid:218)dzy aplikacjami. Jednak ró(cid:285)ni si(cid:218) ona od przedstawionych wcze(cid:258)niej mechanizmów sposobem przekazywania informacji pomi(cid:218)dzy systemami. Rozwi(cid:200)zania zdalnego dost(cid:218)pu typu RMI czy Hessian/Burlap s(cid:200) synchroniczne. Jak pokazano na rysunku 17.1, klient wywo(cid:239)uj(cid:200)cy zdaln(cid:200) metod(cid:218) nie mo(cid:285)e kontynuowa(cid:202) dzia(cid:239)ania, dopóki metoda si(cid:218) nie zako(cid:241)czy. Nawet je(cid:258)li zdalna metoda nie zwraca (cid:285)adnego wyniku do klienta, i tak musi on wstrzyma(cid:202) swoje dzia(cid:239)anie na czas jej wykonania. Z drugiej strony, kiedy komunikaty s(cid:200) przesy(cid:239)ane asynchronicznie, jak pokazano na rysunku 17.2, klient nie musi czeka(cid:202), a(cid:285) us(cid:239)uga przetworzy komunikat, ani nawet a(cid:285) zostanie on dostarczony. Klient wysy(cid:239)a komunikat i kontynuuje dzia(cid:239)anie, zak(cid:239)adaj(cid:200)c, (cid:285)e pr(cid:218)dzej czy pó(cid:283)niej dotrze on do us(cid:239)ugi i zostanie przez ni(cid:200) przetworzony. Komunikacja asynchroniczna jest lepsza od komunikacji synchronicznej pod kilkoma wzgl(cid:218)dami. Opowiemy o nich ju(cid:285) za chwil(cid:218). Najpierw jednak zobaczmy, w jaki sposób mo(cid:285)na asynchronicznie wysy(cid:239)a(cid:202) komunikaty. Poleć książkęKup książkę 17.1. Krótkie wprowadzenie do asynchronicznej wymiany komunikatów 487 Rysunek 17.1. Podczas komunikacji synchronicznej klient musi czeka(cid:252) na zako(cid:276)czenie operacji Rysunek 17.2. Komunikacja asynchroniczna nie wymaga oczekiwania 17.1.1. Wysy(cid:225)anie komunikatów Wi(cid:218)kszo(cid:258)(cid:202) z nas uwa(cid:285)a us(cid:239)ugi (cid:258)wiadczone przez poczt(cid:218) za oczywisto(cid:258)(cid:202). Ka(cid:285)dego dnia ludzie powierzaj(cid:200) pracownikom tej instytucji miliony listów, kartek i paczek, ufaj(cid:200)c, (cid:285)e dotr(cid:200) one do adresata. (cid:165)wiat jest za du(cid:285)y, aby(cid:258)my dostarczali ka(cid:285)d(cid:200) przesy(cid:239)k(cid:218) w(cid:239)asnor(cid:218)cz- nie, zdajemy si(cid:218) wi(cid:218)c w tym zakresie na system pocztowy. Adresujemy j(cid:200), naklejamy znaczek i wrzucamy do skrzynki, nie zastanawiaj(cid:200)c si(cid:218) nawet, jak dotrze do celu. Kluczowym aspektem us(cid:239)ugi pocztowej jest po(cid:258)rednictwo. Dor(cid:218)czenie kartki bezpo(cid:258)rednio do babci w dniu jej urodzin by(cid:239)oby raczej k(cid:239)opotliwe. W zale(cid:285)no(cid:258)ci od tego, gdzie mieszka, mog(cid:239)oby zaj(cid:200)(cid:202) od kilku godzin do kilku dni. Na szcz(cid:218)(cid:258)cie, poczta jest w stanie dostarczy(cid:202) kartk(cid:218), podczas gdy my zajmujemy si(cid:218) swoimi sprawami. Po(cid:258)rednictwo jest równie(cid:285) kluczowe przy asynchronicznej wymianie komunikatów. Kiedy jedna aplikacja wysy(cid:239)a komunikat do drugiej, nie istnieje bezpo(cid:258)rednie po(cid:239)(cid:200)- czenie mi(cid:218)dzy aplikacjami. Zamiast tego wysy(cid:239)aj(cid:200)ca aplikacja powierza komunikat us(cid:239)udze, której zadaniem jest jego dostarczenie aplikacji odbieraj(cid:200)cej. Dwa najwa(cid:285)niejsze poj(cid:218)cia zwi(cid:200)zane z asynchroniczn(cid:200) wymian(cid:200) komunikatów to: brokery komunikatów (ang. message brokers) i miejsca docelowe (ang. destinations). Kiedy aplikacja wysy(cid:239)a komunikat, przekazuje go brokerowi komunikatów. Broker komunikatów jest odpowiednikiem poczty. Zapewni on dor(cid:218)czenie komunikatu do okre(cid:258)lonego adresata, nie anga(cid:285)uj(cid:200)c w ca(cid:239)y proces nadawcy. Gdy wysy(cid:239)asz list poczt(cid:200), wa(cid:285)ne jest, by by(cid:239) on odpowiednio zaadresowany, dzi(cid:218)ki czemu pracownicy poczty b(cid:218)d(cid:200) wiedzie(cid:202), gdzie maj(cid:200) go dostarczy(cid:202). Tak(cid:285)e asynchro- nicznie przesy(cid:239)ane komunikaty posiadaj(cid:200) rodzaj adresu — miejsce docelowe. Miejsca docelowe mo(cid:285)na porówna(cid:202) do skrzynek pocztowych, w których umieszczane s(cid:200) komu- nikaty czekaj(cid:200)ce, a(cid:285) kto(cid:258) je odbierze. Ale w przeciwie(cid:241)stwie do adresów pocztowych, które mog(cid:200) wskazywa(cid:202) okre(cid:258)lon(cid:200) osob(cid:218) lub ulic(cid:218) i numer domu, miejsca docelowe s(cid:200) mniej konkretne. Miejsca docelowe skupiaj(cid:200) si(cid:218) tylko na tym, gdzie komunikat b(cid:218)dzie odebrany — nie na tym, kto go odbie- rze. Pod tym wzgl(cid:218)dem komunikaty przypominaj(cid:200) wysy(cid:239)anie listów „do aktualnego lokatora”. Poleć książkęKup książkę 488 ROZDZIA(cid:224) 17. Obs(cid:239)uga komunikatów w Springu Cho(cid:202) ró(cid:285)ne systemy obs(cid:239)ugi komunikatów mog(cid:200) udost(cid:218)pnia(cid:202) wiele ró(cid:285)nych sys- temów ich rozsy(cid:239)ania i kierowania, to mo(cid:285)na wskaza(cid:202) dwa najpopularniejsze rodzaje miejsc docelowych: kolejki (ang. queues) i tematy (ang. topics). Ka(cid:285)de z nich jest zwi(cid:200)- zane z okre(cid:258)lonym modelem obs(cid:239)ugi komunikatów — punkt-punkt (ang. point-to-point) w przypadku kolejek i publikacja-subskrypcja (ang. publish-subscribe) w przypadku tematów. OBS(cid:224)UGA KOMUNIKATÓW TYPU PUNKT-PUNKT W modelu punkt-punkt ka(cid:285)dy komunikat ma dok(cid:239)adnie jednego nadawc(cid:218) i jednego odbiorc(cid:218), co pokazano na rysunku 17.3. Broker komunikatów po otrzymaniu komunikatu umieszcza go w kolejce. Kiedy odbiorca zg(cid:239)asza si(cid:218) po nast(cid:218)pny komunikat z kolejki, komunikat jest z niej pobierany i dostarczany odbiorcy. Poniewa(cid:285) podczas dostarczania komunikat jest usuwany z kolejki, mo(cid:285)emy by(cid:202) pewni, (cid:285)e nie trafi do wi(cid:218)cej ni(cid:285) jednego odbiorcy. Rysunek 17.3. Kolejka komunikatów oddziela nadawc(cid:266) komunikatu od odbiorcy. Kolejka mo(cid:298)e mie(cid:252) kilku odbiorców, natomiast ka(cid:298)dy komunikat ma dok(cid:225)adnie jednego To, (cid:285)e ka(cid:285)dy komunikat w kolejce jest dor(cid:218)czany tylko jednemu odbiorcy, nie oznacza, (cid:285)e tylko jeden odbiorca pobiera komunikaty z kolejki. Komunikaty z kolejki mog(cid:200) by(cid:202) przetwarzane przez kilku odbiorców. Ka(cid:285)dy z nich przetwarza jednak swoje w(cid:239)asne komunikaty. Proces mo(cid:285)na porówna(cid:202) do czekania w kolejce w banku. Przy transakcji mo(cid:285)e Ci pomóc jeden z kilku kasjerów. Po obs(cid:239)u(cid:285)eniu klienta kasjer jest wolny i prosi nast(cid:218)pn(cid:200) osob(cid:218) z kolejki. Gdy nadchodzi Twoja kolej, zostajesz poproszony do okienka i obs(cid:239)u- (cid:285)ony przez jednego kasjera. Pozostali kasjerzy obs(cid:239)u(cid:285)(cid:200) innych klientów. Kolejn(cid:200) analogi(cid:200) z bankiem jest to, (cid:285)e podczas gdy stoisz w kolejce, z regu(cid:239)y nie wiesz, który kasjer Ci(cid:218) obs(cid:239)u(cid:285)y. Mo(cid:285)esz policzy(cid:202) liczb(cid:218) oczekuj(cid:200)cych w kolejce, skon- frontowa(cid:202) j(cid:200) z liczb(cid:200) kasjerów i spróbowa(cid:202) zgadn(cid:200)(cid:202), który kasjer zawo(cid:239)a Ci(cid:218) do okienka. Szanse, (cid:285)e si(cid:218) pomylisz, s(cid:200) jednak bardzo du(cid:285)e. Podobnie jest w przypadku modelu obs(cid:239)ugi komunikatów punkt-punkt, je(cid:258)li wielu odbiorców nas(cid:239)uchuje komunikatów z kolejki, nie wiadomo, który ostatecznie prze- tworzy konkretny komunikat. Ta niepewno(cid:258)(cid:202) jest dobra, umo(cid:285)liwia bowiem aplikacji zwi(cid:218)kszenie zaanga(cid:285)owania w przetwarzanie komunikatów poprzez proste dodanie kolejnego odbiorcy. OBS(cid:224)UGA KOMUNIKATÓW TYPU PUBLIKACJA-SUBSKRYPCJA W modelu obs(cid:239)ugi komunikatów publikacja-subskrypcja komunikaty s(cid:200) wysy(cid:239)ane do tematu. Tak jak w przypadku kolejek, wielu odbiorców nas(cid:239)uchuje komunikatów z tematu. Ale w przeciwie(cid:241)stwie do kolejek, gdzie dany komunikat jest dor(cid:218)czany tylko i wy(cid:239)(cid:200)cznie jednemu odbiorcy, wszyscy subskrybenci tematu otrzymaj(cid:200) kopi(cid:218) komu- nikatu (rysunek 17.4). Poleć książkęKup książkę 17.1. Krótkie wprowadzenie do asynchronicznej wymiany komunikatów 489 Jak (cid:239)atwo wywnioskowa(cid:202) z nazwy, model publikacja-subskrypcja jest analogi(cid:200) do wydawcy czasopisma i jego prenumeratorów. Czasopismo (komunikat) jest publikowane i wysy(cid:239)ane poczt(cid:200), ka(cid:285)dy prenumerator otrzymuje jedn(cid:200) kopi(cid:218). Analogia z czasopismem upada, kiedy zdamy sobie spraw(cid:218), (cid:285)e w przypadku asyn- chronicznej wymiany komunikatów wydawca nie ma poj(cid:218)cia o tym, kto jest subskry- bentem. Wydawca wie tylko, (cid:285)e komunikat zostanie opublikowany w danym temacie — nie ma (cid:285)adnych informacji o odbiorcach tematu. A co za tym idzie, nie wie, w jaki sposób komunikat zostanie przetworzony. Teraz, kiedy omówili(cid:258)my ju(cid:285) podstawy asynchronicznej wymiany komunikatów, spróbujmy porówna(cid:202) j(cid:200) do synchronicznego RPC. Rysunek 17.4. Podobnie jak kolejki, tematy oddzielaj(cid:261) nadawców komunikatów od ich odbiorców, z t(cid:261) ró(cid:298)nic(cid:261), (cid:298)e komunikat tematu mo(cid:298)e zosta(cid:252) dostarczony do wielu subskrybentów tematu 17.1.2. Szacowanie korzy(cid:286)ci zwi(cid:261)zanych ze stosowaniem asynchronicznej wymiany komunikatów Chocia(cid:285) intuicyjna i prosta w instalacji, komunikacja synchroniczna narzuca pewne ograniczenia po stronie klienta zdalnej us(cid:239)ugi. Oto kilka najwa(cid:285)niejszych: (cid:81) Komunikacja synchroniczna wi(cid:200)(cid:285)e si(cid:218) z oczekiwaniem. Kiedy klient wywo(cid:239)uje metod(cid:218) zdalnej us(cid:239)ugi, musi poczeka(cid:202) na jej zako(cid:241)czenie przed wykonaniem kolejnych zada(cid:241). Je(cid:258)li klient komunikuje si(cid:218) ze zdaln(cid:200) us(cid:239)ug(cid:200) cz(cid:218)sto lub (i) oczekiwanie na odpowied(cid:283) zdalnej us(cid:239)ugi trwa d(cid:239)ugo, mo(cid:285)e to negatywnie wp(cid:239)yn(cid:200)(cid:202) na wydajno(cid:258)(cid:202) aplikacji klienta. (cid:81) Klient jest uzale(cid:285)niony do us(cid:239)ugi przez jej interfejs, którego u(cid:285)ywa. Je(cid:285)eli inter- fejs us(cid:239)ugi si(cid:218) zmieni, konieczna b(cid:218)dzie równie(cid:285) modyfikacja klientów us(cid:239)ugi. (cid:81) Klient jest uzale(cid:285)niony od adresu us(cid:239)ugi. Musi mu zosta(cid:202) podany adres us(cid:239)ugi, aby móg(cid:239) si(cid:218) z ni(cid:200) po(cid:239)(cid:200)czy(cid:202). Je(cid:258)li topologia sieci si(cid:218) zmieni, klient b(cid:218)dzie musia(cid:239) zosta(cid:202) skonfigurowany ponownie, z uwzgl(cid:218)dnieniem nowego adresu. (cid:81) Klient jest uzale(cid:285)niony od dost(cid:218)pno(cid:258)ci us(cid:239)ugi. Gdy us(cid:239)uga jest niedost(cid:218)pna, klient nie mo(cid:285)e z niej skorzysta(cid:202). Poleć książkęKup książkę 490 ROZDZIA(cid:224) 17. Obs(cid:239)uga komunikatów w Springu Chocia(cid:285) komunikacja synchroniczna ma swoje zastosowania, przy ocenianiu potrzeb aplikacji w zakresie mechanizmu komunikacji powinni(cid:258)my wzi(cid:200)(cid:202) pod uwag(cid:218) jej wszyst- kie wy(cid:285)ej wymienione wady. Je(cid:285)eli ograniczenia te s(cid:200) dla Ciebie istotne, z pewno(cid:258)ci(cid:200) zainteresuje Ci(cid:218), jak radzi sobie z nimi asynchroniczna wymiana komunikatów. BEZ CZEKANIA Kiedy komunikat jest wysy(cid:239)any asynchronicznie, klient nie musi czeka(cid:202) na jego przetwo- rzenie ani nawet dostarczenie. Zostawia komunikat w brokerze komunikatów i konty- nuuje dzia(cid:239)anie, ufaj(cid:200)c, (cid:285)e komunikat dotrze do odpowiedniego miejsca docelowego. Poniewa(cid:285) nie musi czeka(cid:202), klient dostaje woln(cid:200) r(cid:218)k(cid:218) w wykonywaniu dalszych dzia(cid:239)a(cid:241). Powoduje to znacz(cid:200)cy wzrost wydajno(cid:258)ci klienta. CENTRALNA ROLA KOMUNIKATÓW I ODDZIELENIE NADAWCY OD ODBIORCY W przeciwie(cid:241)stwie do komunikacji RPC, która najcz(cid:218)(cid:258)ciej koncentruje si(cid:218) wokó(cid:239) wywo(cid:239)ania metody, asynchronicznie wysy(cid:239)ane komunikaty skupiaj(cid:200) si(cid:218) na danych. Oznacza to, (cid:285)e klient nie jest przypisany na sta(cid:239)e do konkretnej sygnatury metody. Ka(cid:285)dy odbiorca kolejki lub subskrybent tematu, który potrafi przetworzy(cid:202) przes(cid:239)ane przez klienta dane, potrafi przetworzy(cid:202) komunikat. Klient nie musi zna(cid:202) szczegó(cid:239)ów us(cid:239)ugi. NIEZALE(cid:297)NO(cid:285)(cid:251) OD ADRESU Synchroniczne us(cid:239)ugi RPC s(cid:200) z regu(cid:239)y lokalizowane za pomoc(cid:200) adresu sieciowego. Na skutek tego aplikacje klienckie nie s(cid:200) odporne na zmiany w topologii sieci. Je(cid:258)li adres IP us(cid:239)ugi ulegnie zmianie lub je(cid:258)li zacznie ona nas(cid:239)uchiwa(cid:202) na innym porcie, klient musi zosta(cid:202) odpowiednio zmodyfikowany, inaczej nie b(cid:218)dzie móg(cid:239) skorzysta(cid:202) z us(cid:239)ugi. Aplikacje klienckie korzystaj(cid:200)ce z asynchronicznej wymiany komunikatów nie maj(cid:200) natomiast poj(cid:218)cia, kto przetworzy ich komunikaty ani gdzie znajduje si(cid:218) us(cid:239)uga. Klient zna tylko kolejk(cid:218) lub temat, przez które komunikat zostanie wys(cid:239)any. Nie ma dla niego znaczenia lokalizacja us(cid:239)ugi, liczy si(cid:218) tylko mo(cid:285)liwo(cid:258)(cid:202) pobierania komunikatów z kolejki lub tematu. W modelu punkt-punkt dzi(cid:218)ki niezale(cid:285)no(cid:258)ci od adresu mo(cid:285)na utworzy(cid:202) klaster us(cid:239)ug. Skoro klient nie musi zna(cid:202) adresu us(cid:239)ugi, a jedynym jej wymaganiem jest, aby mia(cid:239) dost(cid:218)p do brokera komunikatów, nie ma powodu, dla którego wiele us(cid:239)ug nie mo(cid:285)e pobiera(cid:202) komunikatów z tej samej kolejki. Je(cid:258)li us(cid:239)uga jest nadmiernie obci(cid:200)- (cid:285)ona i nie nad(cid:200)(cid:285)a z przetwarzaniem, wystarczy doda(cid:202) kilka nowych instancji us(cid:239)ugi odbieraj(cid:200)cych komunikaty z tej samej kolejki. Niezale(cid:285)no(cid:258)(cid:202) od adresu ma jeszcze jeden interesuj(cid:200)cy efekt uboczny w modelu publikacja-subskrypcja. Wiele us(cid:239)ug mo(cid:285)e subskrybowa(cid:202) ten sam temat, otrzymuj(cid:200)c podwójne kopie tych samych komunikatów. Ale ka(cid:285)da mog(cid:239)aby przetworzy(cid:202) ten komu- nikat inaczej. Powiedzmy na przyk(cid:239)ad, (cid:285)e mamy zestaw us(cid:239)ug, które przetwarzaj(cid:200) komunikat zawieraj(cid:200)cy szczegó(cid:239)y zatrudnienia nowego pracownika. Jedna z us(cid:239)ug mo(cid:285)e doda(cid:202) pracownika do systemu p(cid:239)ac, druga do portalu HR, jeszcze inna dopilnowa(cid:202), (cid:285)eby pracownik mia(cid:239) dost(cid:218)p do systemów, które b(cid:218)d(cid:200) mu potrzebne w pracy. Ka(cid:285)da us(cid:239)uga operuje niezale(cid:285)nie na tych samych danych, pobranych z tematu. Poleć książkęKup książkę 17.2. Wysy(cid:239)anie komunikatów przy u(cid:285)yciu JMS 491 GWARANCJA DOSTARCZENIA Aby klient móg(cid:239) po(cid:239)(cid:200)czy(cid:202) si(cid:218) z synchroniczn(cid:200) us(cid:239)ug(cid:200), us(cid:239)uga musi nas(cid:239)uchiwa(cid:202) na okre(cid:258)lonym porcie pod okre(cid:258)lonym adresem IP. W razie awarii us(cid:239)ugi klient nie b(cid:218)dzie móg(cid:239) kontynuowa(cid:202) dzia(cid:239)ania. Przy asynchronicznym wysy(cid:239)aniu komunikatów klient ma pewno(cid:258)(cid:202), (cid:285)e jego komu- nikaty b(cid:218)d(cid:200) dostarczone. Nawet gdy us(cid:239)uga jest niedost(cid:218)pna podczas wysy(cid:239)ania komu- nikatu, komunikat zostanie przechowany do czasu jej wznowienia. Teraz gdy znamy ju(cid:285) podstawy asynchronicznej wymiany komunikatów, mo(cid:285)emy przyjrze(cid:202) si(cid:218) jej w dzia(cid:239)aniu. Zaczniemy od wysy(cid:239)ania i odbierania komunikatów przy u(cid:285)yciu JMS. 17.2. Wysy(cid:225)anie komunikatów przy u(cid:298)yciu JMS Java Message Service (w skrócie: JMS) to standard Javy definiuj(cid:200)cy wspólny interfejs API s(cid:239)u(cid:285)(cid:200)cy do korzystania z brokerów komunikatów. Przed wprowadzeniem JMS ka(cid:285)dy broker komunikatów udost(cid:218)pnia(cid:239) swój w(cid:239)asny API, znacz(cid:200)co ograniczaj(cid:200)c mo(cid:285)- liwo(cid:258)ci przenoszenia kodu aplikacji i wykorzystania innego brokera. Jednak obecnie dzi(cid:218)ki JMS wszystkie implementacje zgodne z tym standardem mog(cid:200) by(cid:202) obs(cid:239)ugiwane przy u(cid:285)yciu jednego, wspólnego interfejsu — podobnie jak JDBC udost(cid:218)pnia wspólny interfejs do obs(cid:239)ugi baz danych. Spring obs(cid:239)uguje JMS przy u(cid:285)yciu abstrakcji bazuj(cid:200)cej na szablonach, a konkret- nie — szablonu JmsTemplate. Korzystaj(cid:200)c z niego, mo(cid:285)na w prosty sposób wysy(cid:239)a(cid:202) komunikaty do kolejek i tematów (po stronie producenta) oraz odbiera(cid:202) komunikaty (po stronie klienta). Spring obs(cid:239)uguje tak(cid:285)e notacj(cid:218) obiektów POJO sterowanych komu- nikatami: zwyczajnych obiektów Javy reaguj(cid:200)cych na komunikaty asynchronicznie nadsy(cid:239)ane do kolejki lub tematu. W tym rozdziale przyjrzymy si(cid:218) mechanizmom korzystania z JSM dost(cid:218)pnym w Springu, w tym szablonowi JmsTemplate oraz obiektom POJO sterowanym komunika- tami. Jednak zanim b(cid:218)dziemy mogli wysy(cid:239)a(cid:202) i odbiera(cid:202) komunikaty, musimy przygotowa(cid:202) brokera komunikatów, który b(cid:218)dzie po(cid:258)redniczy(cid:239) w ich wymianie pomi(cid:218)dzy produ- centami a konsumentami. Zacznijmy zatem nasz(cid:200) przygod(cid:218) z JMS w Springu od skonfigurowania brokera komunikatów. 17.2.1. Konfiguracja brokera komunikatów w Springu ActiveMQ, broker komunikatów o otwartym kodzie, jest doskona(cid:239)ym wyborem, je(cid:258)li cho- dzi o asynchroniczn(cid:200) obs(cid:239)ug(cid:218) komunikatów za pomoc(cid:200) JMS. W momencie pisania tych s(cid:239)ów najnowsza wersja ActiveMQ ma numer 5.11.1. Aby rozpocz(cid:200)(cid:202) prac(cid:218) z ActiveMQ, musimy pobra(cid:202) plik dystrybucji binarnej z http://activemq.apache.org. Po pobraniu rozpakujemy zawarto(cid:258)(cid:202) archiwum na lokalny dysk. W katalogu lib rozpakowanej dys- trybucji znajdziemy plik activemq-core-5.11.1.jar. Plik ten musi zosta(cid:202) dodany do (cid:258)cie(cid:285)ki do klas aplikacji, aby korzystanie z API ActiveMQ by(cid:239)o mo(cid:285)liwe. Poleć książkęKup książkę 492 ROZDZIA(cid:224) 17. Obs(cid:239)uga komunikatów w Springu W katalogu bin znajdziemy szereg podkatalogów dla ró(cid:285)nych systemów operacyj- nych. To w nich znajduj(cid:200) si(cid:218) skrypty s(cid:239)u(cid:285)(cid:200)ce do uruchomienia ActiveMQ. Na przyk(cid:239)ad, aby uruchomi(cid:202) ActiveMQ w systemie OS X1, wydaj komend(cid:218) activemq start z kata- logu macosx. Ju(cid:285) po chwili ActiveMQ b(cid:218)dzie gotowy do przetwarzania komunikatów. TWORZENIE FABRYKI PO(cid:224)(cid:260)CZE(cid:275) W tym rozdziale poka(cid:285)emy ró(cid:285)ne przyk(cid:239)ady u(cid:285)ycia Springa do wysy(cid:239)ania i odbierania komunikatów za pomoc(cid:200) JMS. W ka(cid:285)dym z nich potrzebowa(cid:202) b(cid:218)dziemy fabryki po(cid:239)(cid:200)- cze(cid:241), aby móc wysy(cid:239)a(cid:202) komunikaty przez brokera komunikatów. Jako (cid:285)e naszym bro- kerem komunikatów jest ActiveMQ, b(cid:218)dziemy musieli skonfigurowa(cid:202) fabryk(cid:218) po(cid:239)(cid:200)- cze(cid:241) JMS do po(cid:239)(cid:200)czenia z ActiveMQ. ActiveMQ dostarcza fabryk(cid:218) po(cid:239)(cid:200)cze(cid:241) JMS ActiveMQConnectionFactory, któr(cid:200) konfiguruje si(cid:218) w Springu nast(cid:218)puj(cid:200)co: bean id= connectionFactory class= org.apache.activemq.spring.ActiveMQConnectionFactory /bean Domy(cid:258)lnie ActiveMQConnectionFactory zak(cid:239)ada, (cid:285)e broker ActiveMQ nas(cid:239)uchuje na porcie 61616 lokalnego komputera (localhost). Takie rozwi(cid:200)zanie w zupe(cid:239)no(cid:258)ci wystar- cza na potrzeby tworzenia aplikacji, cho(cid:202) produkcyjny broker ActiveMQ najprawdo- podobniej b(cid:218)dzie musia(cid:239) dzia(cid:239)a(cid:202) na innym komputerze b(cid:200)d(cid:283) porcie. W takim przy- padku adres URL brokera mo(cid:285)na okre(cid:258)li(cid:202) przy u(cid:285)yciu w(cid:239)a(cid:258)ciwo(cid:258)ci brokerURL: bean id= connectionFactory class= org.apache.activemq.spring.ActiveMQConnectionFactory p:brokerURL= tcp://localhost:61616 / Ewentualnie, poniewa(cid:285) wiemy, (cid:285)e mamy do czynienia z ActiveMQ, do deklaracji fabryki po(cid:239)(cid:200)cze(cid:241) mo(cid:285)emy te(cid:285) u(cid:285)y(cid:202) konfiguracyjnej przestrzeni nazw Springa dla ActiveMQ (dost(cid:218)pnej dla wszystkich wersji ActiveMQ, pocz(cid:200)wszy od wersji 4.1). Zaczniemy od deklaracji przestrzeni nazw amq w pliku konfiguracyjnym XML Springa: ?xml version= 1.0 encoding= UTF-8 ? beans xmlns= http://www.springframework.org/schema/beans xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance xmlns:jms= http://www.springframework.org/schema/jms xmlns:amq= http://activemq.apache.org/schema/core xsi:schemaLocation= http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd ... /beans Nast(cid:218)pnie u(cid:285)yjemy elementu amq:connectionFactory do deklaracji fabryki po(cid:239)(cid:200)cze(cid:241): amq:connectionFactory id= connectionFactory brokerURL= tcp://localhost:61616 / 1 Instrukcje instalacji ActiveMQ w pozosta(cid:239)ych systemach operacyjnych mo(cid:285)na znale(cid:283)(cid:202) pod adresem http://activemq.apache.org/getting-started.html — przyp. t(cid:239)um. Poleć książkęKup książkę 17.2. Wysy(cid:239)anie komunikatów przy u(cid:285)yciu JMS 493 Zwró(cid:202) uwag(cid:218), (cid:285)e element amq:connectionFactory jest charakterystyczny dla ActiveMQ. Dla innej implementacji brokera komunikatów konfiguracyjna przestrze(cid:241) nazw Springa mo(cid:285)e, ale nie musi istnie(cid:202). W przypadku jej braku fabryka po(cid:239)(cid:200)cze(cid:241) musi zosta(cid:202) dowi(cid:200)- zana jako bean . W dalszej cz(cid:218)(cid:258)ci rozdzia(cid:239)u b(cid:218)dziemy u(cid:285)ywa(cid:202) komponentu connectionFactory bardzo cz(cid:218)sto. W tej chwili jednak wystarczy nam wiedza, (cid:285)e atrybut brokerURL informuje fabryk(cid:218) po(cid:239)(cid:200)cze(cid:241) o adresie brokera komunikatów. W naszym przyk(cid:239)adzie podany w atrybucie brokerURL adres URL sugeruje fabryce po(cid:239)(cid:200)cze(cid:241) po(cid:239)(cid:200)czenie z ActiveMQ na porcie 61616 lokalnego komputera (na tym porcie ActiveMQ nas(cid:239)uchuje domy(cid:258)lnie). DEKLARACJA MIEJSCA DOCELOWEGO KOMUNIKATÓW ACTIVEMQ Oprócz fabryki po(cid:239)(cid:200)cze(cid:241) potrzebowa(cid:202) b(cid:218)dziemy miejsca docelowego, do którego komunikaty b(cid:218)d(cid:200) dostarczane. Miejsce docelowe mo(cid:285)e by(cid:202) albo kolejk(cid:200), albo tematem, w zale(cid:285)no(cid:258)ci od potrzeb aplikacji. Bez wzgl(cid:218)du na to, czy u(cid:285)ywamy kolejki czy tematu, musimy skonfigurowa(cid:202) kom- ponent miejsca docelowego w Springu za pomoc(cid:200) implementacji klasy specyficznej dla brokera komunikatów. Na przyk(cid:239)ad poni(cid:285)szy komponent deklaruje kolejk(cid:218) ActiveMQ: bean id= queue class= org.apache.activemq.command.ActiveMQQueue c:_= spitter.queue / /bean Analogiczny komponent deklaruj(cid:200)cy temat ActiveMQ przedstawia si(cid:218) nast(cid:218)puj(cid:200)co: bean id= topic class= org.apache.activemq.command.ActiveMQTopic c:_= spitter.queue / W obu przypadkach do konstruktora jest przekazywana nazwa kolejki, po której jest ona identyfikowana przez brokera komunikatów. W naszym przyk(cid:239)adzie jest to spitter. (cid:180)topic. Podobnie jak przy fabryce po(cid:239)(cid:200)cze(cid:241), przestrze(cid:241) nazw ActiveMQ oferuje nam al- ternatywn(cid:200) metod(cid:218) deklaracji kolejek i tematów. Dla kolejek mo(cid:285)emy u(cid:285)y(cid:202) elementu amq:queue : amq:queue id= spittleQueue physicalName= spitter.alert.queue / A dla tematów JMS elementu amq:topic : amq:topic id= spittleTopic physicalName= spitter.alert.topic / W obu przypadkach atrybut physicalName jest nazw(cid:200) kana(cid:239)u komunikatów. Na tym etapie wiemy ju(cid:285), jak zadeklarowa(cid:202) wszystkie komponenty niezb(cid:218)dne do pracy z JMS, niezale(cid:285)nie od tego, czy chcemy wysy(cid:239)a(cid:202) komunikaty, czy je odbiera(cid:202). Jeste(cid:258)my ju(cid:285) wi(cid:218)c gotowi do rozpocz(cid:218)cia komunikacji. U(cid:285)yjemy do tego szablonu JmsTemplate, który stanowi trzon obs(cid:239)ugi JMS przez Springa. Najpierw jednak, aby doceni(cid:202) korzy(cid:258)ci p(cid:239)yn(cid:200)ce z tego szablonu, zobaczmy, jak wygl(cid:200)da JMS bez JmsTemplate. Poleć książkęKup książkę 494 ROZDZIA(cid:224) 17. Obs(cid:239)uga komunikatów w Springu 17.2.2. Szablon JMS Springa Jak ju(cid:285) wiemy, JMS daje programistom Javy standardowe API do interakcji z broke- rami komunikatów oraz wysy(cid:239)ania i obierania komunikatów. Ma(cid:239)o tego: praktycznie ka(cid:285)da implementacja brokera komunikatów obs(cid:239)uguje JMS. Nie ma wi(cid:218)c potrzeby nauki niestandardowego API obs(cid:239)ugi komunikatów przy ka(cid:285)dym nowym brokerze. Ale cho(cid:202) JMS oferuje interfejs uniwersalny dla wszystkich brokerów komunikatów, nie dostajemy tego za darmo. Wysy(cid:239)anie i odbieranie komunikatów za pomoc(cid:200) JMS nie jest tak proste, jak przyklejenie znaczka na kopert(cid:218). U(cid:285)ywaj(cid:200)c przeno(cid:258)ni, mo(cid:285)na by powiedzie(cid:202), (cid:285)e wymaga jeszcze dodatkowo zatankowania furgonetki przewo(cid:283)nika poczty. KOD JMS A OBS(cid:224)UGA WYJ(cid:260)TKÓW W punkcie 10.3.1 zaprezentowa(cid:239)em przyk(cid:239)ad tradycyjnego kodu JDBC, przypomina- j(cid:200)cego bardziej bez(cid:239)adn(cid:200) mas(cid:218) kodu do obs(cid:239)ugi po(cid:239)(cid:200)cze(cid:241), wyra(cid:285)e(cid:241), zbiorów wynikowych i wyj(cid:200)tków. Niestety, tradycyjny kod JMS wydaje si(cid:218) pod(cid:200)(cid:285)a(cid:202) t(cid:200) sam(cid:200) drog(cid:200), co da si(cid:218) zaobserwowa(cid:202) na listingu 17.1. Listing 17.1. Wysy(cid:225)anie komunikatu przy u(cid:298)yciu tradycyjnego JMS (bez Springa) ConnectionFactory cf = new ActiveMQConnectionFactory( tcp://localhost:61616 ); Connection conn = null; Session session = null; try { conn = cf.createConnection(); session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE); Destination destination = new ActiveMQQueue( spitter.queue ); MessageProducer producer = session.createProducer(destination); TextMessage message = session.createTextMessage(); Wy(cid:286)lij komunikat message.setText( Witaj, (cid:295)wiecie! ); producer.send(message); } catch (JMSException e) { // obs(cid:239)uga wyj(cid:200)tku? } finally { try { if (session != null) { session.close(); } if (conn != null) { conn.close(); } } catch (JMSException ex) { } } Gdzie(cid:258) to ju(cid:285) chyba mówi(cid:239)em, ale to ca(cid:239)kiem poka(cid:283)ny kawa(cid:239)ek kodu! Zupe(cid:239)nie jak w przyk(cid:239)adzie JDBC, prawie 20 wierszy tylko po to, (cid:285)eby wys(cid:239)a(cid:202) prosty komunikat „Witaj, (cid:258)wiecie!”. Za samo wys(cid:239)anie komunikatu odpowiada tak naprawd(cid:218) tylko kilka wierszy kodu. Reszta s(cid:239)u(cid:285)y tylko do stworzenia warunków dla tej operacji. Po stronie odbiorcy sytuacja wygl(cid:200)da niewiele lepiej; spójrzmy na listing 17.2. Poleć książkęKup książkę 17.2. Wysy(cid:239)anie komunikatów przy u(cid:285)yciu JMS 495 Listing 17.2. Odbieranie komunikatu przy u(cid:298)yciu tradycyjnego JMS (bez Springa) ConnectionFactory cf = new ActiveMQConnectionFactory( tcp://localhost:61616 ); Connection conn = null; Session session = null; try { conn = cf.createConnection(); conn.start(); session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE); Destination destination = new ActiveMQQueue( spitter.queue ); MessageConsumer consumer = session.createConsumer(destination); Message message = consumer.receive(); TextMessage textMessage = (TextMessage) message; System.out.println( OTRZYMANO KOMUNIKAT: + textMessage.getText()); conn.start(); } catch (JMSException e) { // obs(cid:239)uga wyj(cid:200)tku? } finally { try { if (session != null) { session.close(); } if (conn != null) { conn.close(); } } catch (JMSException ex) { } } Podobnie jak na listingu 17.1, to zdecydowanie za du(cid:285)o kodu na co(cid:258) tak prostego. Porów- nuj(cid:200)c oba listingi wiersz po wierszu, zauwa(cid:285)ysz, (cid:285)e s(cid:200) niemal identyczne. I ka(cid:285)dy z tysi(cid:200)ca innych przyk(cid:239)adów JMS by(cid:239)by uderzaj(cid:200)co podobny. Niektóre uzyskiwa(cid:239)yby fabryki po(cid:239)(cid:200)cze(cid:241) z JNDI, inne u(cid:285)ywa(cid:239)y tematu zamiast kolejki. Wszystkie by(cid:239)yby jed- nak skonstruowane wed(cid:239)ug tego samego wzorca. W ten sposób, pracuj(cid:200)c z JMS, powielasz ka(cid:285)dorazowo du(cid:285)e fragmenty swojego kodu JMS. Albo, co nawet gorsze — czyjego(cid:258). W rozdziale 10. zaprezentowali(cid:258)my szablon JdbcTemplate, dzi(cid:218)ki któremu uda(cid:239)o si(cid:218) ograniczy(cid:202) kod JDBC do niezb(cid:218)dnego minimum. Teraz spróbujemy si(cid:218) upora(cid:202) z nadmiarowym kodem JMS w analogiczny sposób, za pomoc(cid:200) szablonu JmsTemplate. PRACA Z SZABLONAMI JMS Szablon JmsTemplate jest odpowiedzi(cid:200) Springa na rozwlek(cid:239)y i pe(cid:239)en powtórze(cid:241) kod JMS. JmsTemplate zajmuje si(cid:218) tworzeniem po(cid:239)(cid:200)czenia, uzyskiwaniem sesji i wreszcie wysy(cid:239)a- niem oraz odbieraniem komunikatów. Dzi(cid:218)ki temu programista mo(cid:285)e si(cid:218) skupi(cid:202) na generowaniu nowych komunikatów i przetwarzaniu otrzymanych. Ponadto, JmsTemplate potrafi obs(cid:239)u(cid:285)y(cid:202) k(cid:239)opotliwy wyj(cid:200)tek JMSException, który mo(cid:285)e zosta(cid:202) w ka(cid:285)dej chwili zg(cid:239)oszony. Je(cid:258)li podczas pracy z JmsTemplate zg(cid:239)oszony zostanie wyj(cid:200)tek JMSException, JmsTemplate przechwyci go i zg(cid:239)osi ponownie w postaci jednego z niekontrolowanych wyj(cid:200)tków, b(cid:218)d(cid:200)cych rozszerzeniem klasy JmsException Springa. Poleć książkęKup książkę 496 ROZDZIA(cid:224) 17. Obs(cid:239)uga komunikatów w Springu W tabeli 17.1 zestawiono standardowe wyj(cid:200)tki JMSException i odpowiadaj(cid:200)ce im niekon- trolowane wyj(cid:200)tki Springa JmsException. Trzeba odda(cid:202) API JMS, (cid:285)e klasa JMSException posiada dosy(cid:202) obszerny i opisowy zbiór podklas, które daj(cid:200) nam pewne poj(cid:218)cie o charakterze b(cid:239)(cid:218)du. Niemniej jednak wszystkie one s(cid:200) klasami wyj(cid:200)tków kontrolowanych, które musz(cid:200) by(cid:202) przechwycone. JmsTemplate zajmuje si(cid:218) tym za nas, przechwytuj(cid:200)c te wyj(cid:200)tki i zg(cid:239)aszaj(cid:200)c je ponownie jako niekon- trolowane podklasy JmsException. Tabela 17.1. Szablon JmsTemplate Springa przechwytuje standardowe wyj(cid:261)tki JMSException i zg(cid:225)asza je ponownie jako niekontrolowane podklasy JmsException Springa Spring (org.springframework.jms.*) Standardowe JMS (javax.jms.*) DestinationResolutionException IllegalStateException InvalidClientIDException InvalidDestinationException InvalidSelectorException JmsSecurityException ListenerExecutionFailedException MessageConversionException MessageEOFException MessageFormatException MessageNotReadableException MessageNotWriteableException ResourceAllocationException SynchedLocalTransactionFailedException TransactionInProgressException TransactionRolledBackException UncategorizedJmsException Specyficzny dla Springa — zg(cid:225)aszany, gdy Spring nie jest w stanie uzyska(cid:252) nazwy miejsca docelowego IllegalStateException InvalidClientIDException InvalidDestinationException InvalidSelectorException JmsSecurityException Specyficzny dla Springa — zg(cid:225)aszany, gdy nie uda si(cid:266) wykona(cid:252) metody odbiorcy Specyficzny dla Springa — zg(cid:225)aszany, gdy konwersja komunikatu si(cid:266) nie powiedzie MessageEOFException MessageFormatException MessageNotReadableException MessageNotWriteableException ResourceAllocationException Specyficzny dla Springa — zg(cid:225)aszany przy b(cid:225)(cid:266)dzie zsynchronizowanej lokalnej transakcji TransactionInProgressException TransactionRolledBackException Specyficzny dla Springa — zg(cid:225)aszany w sytuacji, gdy nie mo(cid:298)na zastosowa(cid:252) (cid:298)adnego innego wyj(cid:261)tku Aby u(cid:285)y(cid:202) szablonu JmsTemplate, musimy zadeklarowa(cid:202) go jako komponent w pliku konfiguracyjnym Springa. Poni(cid:285)szy fragment kodu XML powinien wystarczy(cid:202): bean id= jmsTemplate class= org.springframework.jms.core.JmsTemplate c:_-ref= connectionFactory / Poniewa(cid:285) JmsTemplate powinien wiedzie(cid:202), jak pozyskiwa(cid:202) po(cid:239)(cid:200)czenia do brokera komu- nikatów, we w(cid:239)a(cid:258)ciwo(cid:258)ci connectionFactory musimy poda(cid:202) referencj(cid:218) do komponentu implementuj(cid:200)cego interfejs ConnectionFactory JMS. W przyk(cid:239)adzie powy(cid:285)ej dowi(cid:200)- zali(cid:258)my referencj(cid:218) do zadeklarowanego przez nas wcze(cid:258)niej (w punkcie 17.2.1) kompo- nentu connectionFactory. Poleć książkęKup książkę 17.2. Wysy(cid:239)anie komunikatów przy u(cid:285)yciu JMS 497 Tak skonfigurowany szablon JmsTemplate jest gotowy do u(cid:285)ycia. Czas wys(cid:239)a(cid:202) komu- nikaty! WYSY(cid:224)ANIE KOMUNIKATÓW Jedn(cid:200) z wbudowanych funkcji aplikacji Spittr jest opcja powiadamiania (by(cid:202) mo(cid:285)e za pomoc(cid:200) poczty elektronicznej) innych u(cid:285)ytkowników o pojawieniu si(cid:218) nowego spittle’a. Mogliby(cid:258)my wbudowa(cid:202) j(cid:200) bezpo(cid:258)rednio w aplikacj(cid:218), w punkcie, w którym dodawany jest spittle. Ale decyzja, do kogo te powiadomienia wys(cid:239)a(cid:202), a zw(cid:239)aszcza samo ich wys(cid:239)anie, mo(cid:285)e zaj(cid:200)(cid:202) chwil(cid:218). Ten dodatkowy czas mo(cid:285)e zawa(cid:285)y(cid:202) na wydajno(cid:258)ci aplikacji. Podczas tworzenia nowego spittle’a oczekujemy, (cid:285)e aplikacja odpowie b(cid:239)yskawicznie. Zamiast po(cid:258)wi(cid:218)ca(cid:202) cenny czas na wysy(cid:239)anie tych komunikatów w momencie doda- wania spittle’a, bardziej sensownym rozwi(cid:200)zaniem wydaje si(cid:218) umieszczenie tego zada- nia w kolejce, do wykonania ju(cid:285) po otrzymaniu odpowiedzi przez u(cid:285)ytkownika. Czas potrzebny na wys(cid:239)anie komunikatu do kolejki komunikatów jest nieporównywalnie krótszy od czasu, który musieliby(cid:258)my przeznaczy(cid:202) na rozsy(cid:239)anie powiadomie(cid:241) u(cid:285)yt- kownikom. W asynchronicznym wysy(cid:239)aniu powiadomie(cid:241) o nowych spittle’ach pomo(cid:285)e nam nowa us(cid:239)uga aplikacji Spittr — AlertService: package com.habuma.spittr.alerts; import com.habuma.spittr.domain.Spittle; public interface AlertService { void sendSpittleAlert(Spittle spittle); } Jak wida(cid:202), AlertService jest interfejsem definiuj(cid:200)cym tylko jedn(cid:200) operacj(cid:218): sendSpittle (cid:180)Alert(). AlertServiceImpl jest implementacj(cid:200) interfejsu AlertService, która za pomoc(cid:200) wstrzyk- ni(cid:218)tego JmsTemplate (interfejsu u(cid:285)ywanego przez JmsTemplate) wysy(cid:239)a obiekty Spittle do kolejki komunikatów celem pó(cid:283)niejszego przetworzenia. Kod klasy pokazano na listingu 17.3. Listing 17.3. Wysy(cid:225)anie spittle’a z wykorzystaniem JmsTemplate package com.habuma.spittr.alerts; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.Session; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.jms.core.JmsOperations; import org.springframework.jms.core.MessageCreator; import com.habuma.spittr.domain.Spittle; public class AlertServiceImpl implements AlertService { private JmsOperations jmsOperations; @Autowired public AlertServiceImpl(JmsOperations jmsOperatons) { this.jmsOperations = jmsOperations; Wstrzykuje szablon JMS Poleć książkęKup książkę 498 } ROZDZIA(cid:224) 17. Obs(cid:239)uga komunikatów w Springu public void sendSpittleAlert(final Spittle spittle) { jmsOperations.send( spittle.alert.queue , new MessageCreator() { public Message createMessage(Session session) throws JMSException { return session.createObjectMessage(spittle); } } ); } } Wysy(cid:225)a komunikat Okre(cid:286)la miejsce docelowe Tworzy komunikat Pierwszym parametrem metody send() szablonu JmsTemplate jest nazwa miejsca doce- lowego JMS, do którego komunikat zostanie wys(cid:239)any. Po wywo(cid:239)aniu metody send() Jms (cid:180)Template postara si(cid:218) uzyska(cid:202) po(cid:239)(cid:200)czenie JMS i sesj(cid:218), a nast(cid:218)pnie wy(cid:258)le komunikat w imieniu nadawcy (rysunek 17.5). Rysunek 17.5. JmsTemplate wykonuje z(cid:225)o(cid:298)on(cid:261) operacj(cid:266) wys(cid:225)ania komunikatu w imieniu nadawcy Sam komunikat natomiast jest konstruowany za pomoc(cid:200) kreatora komunikatów Message (cid:180)Creator, tu zaimplementowanego jako anonimowa klasa wewn(cid:218)trzna. Metoda kreatora createMessage() zwraca obiekt komunikatu z sesji na podstawie przekazanego obiektu Spittle, z którego buduje komunikat. I po wszystkim! Zauwa(cid:285), (cid:285)e metoda sendSpittleAlert() koncentr
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Spring w akcji. Wydanie IV
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: