Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00134 002775 20870986 na godz. na dobę w sumie
wyszukaj dokładnie | pobierz wtyczkę
Wzorce SOA - książka
Wzorce SOA - książka
Autor: Liczba stron: 320
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-7050-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook (-25%), audiobook).
Czytaj online.
Komentuj

Najlepsze podejście do wytwarzania oprogramowania!

SOA (ang. Service Oriented Architecture) to gorący skrót ostatnich lat. Koncepcja oferowania niezależnych usług do określonych zadań zdobyła sobie ogromną popularność. Takie podejście pozwala na tworzenie elastycznych systemów informatycznych, które są znacznie łatwiejsze w utrzymaniu, zaprojektowaniu i wykonaniu od tradycyjnych rozwiązań. Ponadto udostępnienie pojedynczych serwisów innym projektantom może przynieść dodatkowe dochody lub zwiększyć atrakcyjność Twojej aplikacji.

Prawda, że brzmi zachęcająco? Po przeczytaniu tej książki nie oprzesz się wrażeniu, że jest to jedyna słuszna droga w zakresie wytwarzania oprogramowania. W trakcie lektury dowiesz się, jak zapewnić najwyższą jakość, dostępność i przepustowość tworzonych usług. Poznasz kolejne wzorce, które pozwolą Ci zaprojektować przejrzysty i bezpieczny system. Integracja usług, wymiana danych między serwisami, tworzenie klienta usług to tylko niektóre z poruszanych zagadnień. Osobny rozdział został poświęcony antywzorcom - to obowiązkowy punkt lektury, bo przecież musisz wiedzieć, jak tego nie robić! Sprawdź tę książkę, to kapitalna pozycja dla każdego projektanta i programisty chcącego tworzyć nowoczesne systemy informatyczne.

Dowiedz się:

Lektura obowiązkowa każdego projektanta!

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

Darmowy fragment publikacji:

Tytuł oryginału: SOA Patterns Tłumaczenie: Lech Lachowski Projekt okładki: Anna Mitka ISBN: 978-83-246-7050-5 Original edition copyright © 2012 by Manning Publications Co., as set forth in copyright notice of Proprietor’s edition. All rights reserved. Polish edition copyright © 2013 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. Wydawnictwo HELION dołożyło wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie bierze jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION nie ponosi również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. 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) Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC. Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/wzosoa.zip Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/wzosoa 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Ăci Przedmowa 11 WstÚp 13 O ksiÈĝce 15 O autorze 19 O ilustracji na okïadce 21 CZ}¥m I WZORCE SOA ...................................................................................... 23 Rozdziaï 1. RozwiÈzywanie problemów SOA za pomocÈ wzorców 25 1.1. Definicja architektury oprogramowania 26 1.2. Architektura zorientowana na usïugi 27 1.2.1. Czym jest, a czym nie jest SOA 28 1.2.2. KorzyĂci architektoniczne pïynÈce ze stosowania SOA 31 1.2.3. SOA dla przedsiÚbiorstw 34 Pokonywanie wyzwañ SOA za pomocÈ wzorców 35 1.3.1. Struktura wzorca 35 1.3.2. Od wyizolowanego wzorca do jÚzyka wzorców 38 Podsumowanie 40 1.4. 1.5. Dalsza lektura 40 1.3. Rozdziaï 2. Podstawowe wzorce strukturalne 41 2.1. Wzorzec Host Usïugi 42 2.2. Wzorzec Usïuga Aktywna 48 2.3. Wzorzec Usïuga Transakcyjna 53 2.4. Wzorzec Przepïyw Pracy 59 2.5. Wzorzec Komponent Brzegowy 64 2.6. Podsumowanie 69 2.7. Dalsza lektura 69 Rozdziaï 3. Wzorce dotyczÈce wydajnoĂci, skalowalnoĂci i dostÚpnoĂci 71 3.1. Wzorzec Oddzielone Wywoïanie 73 3.2. Wzorzec Potoki Równolegïe 79 3.3. Wzorzec Usïuga Przetwarzania Sieciowego 84 3.4. Wzorzec Instancja Usïugi 89 3.5. Wzorzec Wirtualny Punkt Koñcowy 93 3.6. Wzorzec Straĝnik Usïugi 96 3.7. Podsumowanie 101 3.8. Dalsza lektura 102 Kup książkęPoleć książkę 8 Spis treĂci Rozdziaï 4. Wzorce dotyczÈce bezpieczeñstwa i zarzÈdzalnoĂci 103 4.1. Wzorzec Bezpieczne Komunikaty 106 4.2. Wzorzec Bezpieczna Infrastruktura 111 4.3. Wzorzec Firewall Usïugi 118 4.4. Wzorzec Dostawca ToĝsamoĂci 123 4.5. Wzorzec Monitor Usïugi 131 4.6. Podsumowanie 138 4.7. Dalsza lektura 139 Rozdziaï 5. Wzorce dotyczÈce wymiany komunikatów 141 5.1. Wzorzec ¿Èdanie/Odpowiedě 143 5.2. Wzorzec ¿Èdanie/Reakcja 149 5.3. Wzorzec Odwrócenie Komunikacji 156 5.4. Wzorzec Saga 165 5.5. Podsumowanie 174 5.6. Dalsza lektura 175 Rozdziaï 6. Wzorce dotyczÈce konsumentów usïug 177 6.1. Wzorzec Rezerwacja 178 6.2. Wzorzec Fasada Kompozytowa (Portal) 187 6.3. Wzorzec Klient/Serwer/Usïuga 193 6.4. Podsumowanie 200 6.5. Dalsza lektura 200 Rozdziaï 7. Wzorce dotyczÈce integracji usïug 203 7.1. Wzorzec Magistrala Usïug 204 7.2. Wzorzec Orkiestracja 213 7.3. Wzorzec Zagregowane Raportowanie 221 7.4. Podsumowanie 231 7.5. Dalsza lektura 231 CZ}¥m II SOA W PRAWDZIWYM ¥WIECIE ......................................................... 233 Rozdziaï 8. Antywzorce usïug 235 8.1. Antywzorzec Supeï 236 8.2. Antywzorzec Nanousïuga 242 8.3. Antywzorzec Integracja Transakcyjna 249 8.4. Antywzorzec Stare Nawyki 254 8.5. Podsumowanie 257 8.6. Dalsza lektura 258 Kup książkęPoleć książkę Rozdziaï 9. Podsumowanie — studium przypadku 259 Spis treĂci 9 Problem 260 9.1. 9.2. RozwiÈzanie 261 9.3. Podsumowanie 280 Rozdziaï 10. SOA a rzeczywistoĂÊ 283 10.1. REST a SOA 284 10.1.1. Co to wïaĂciwie jest REST? 284 10.1.2. Czym róĝniÈ siÚ REST i SOA 286 10.1.3. RESTful SOA 287 10.2. SOA i chmura 288 10.2.1. Zupa technologiczna chmury 289 10.2.2. Chmura i faïszywe przesïanki przetwarzania rozproszonego 290 10.2.3. Chmura i SOA 292 10.3. SOA i big data 293 10.3.1. Mix technologiczny big data 294 10.3.2. Jak dziaïa SOA z big data 296 10.4. Podsumowanie 298 10.5. Dalsza lektura 299 Dodatek Od atrybutów jakoĂciowych do wzorców 301 Skorowidz 311 Kup książkęPoleć książkę 10 Spis treĂci Kup książkęPoleć książkę Wzorce dotyczÈce wymiany komunikatów W tym rozdziale Q Interakcje pomiĊdzy usáugami i konsumentami Q Komunikaty skorelowane Q Czas Īycia zdarzeĔ W rozdziaïach 2. i 3. przyjrzeliĂmy siÚ wzorcom takim jak Komponent Brzegowy i Instancja Usïugi, które pomagajÈ budowaÊ usïugi i ich interfejsy. Rozdziaï 4. zostaï poĂwiÚcony sposobom ochrony i monitorowania usïug. Rozdziaï 5. jest pierwszym z trzech kolejnych rozdziaïów omawiajÈcych róĝne aspekty interakcji usïug. W koñcu to zapewnienie interakcji usïug i umoĝliwienie procesów biznesowych byïo pierw- szym powodem do zastosowania SOA. Jak pokazano na rysunku 5.1, rozdziaï ten skupia siÚ na interakcjach usïug z ich „klientami” — konsumentami usïug. Konsument usïug to dowolny komponent lub fragment kodu, który wspóïdziaïa z usïugÈ. Wzorce omówione w tym rozdziale dotyczÈ podstaw — wymiany komunikatów. Rozdziaï 6. zostaï poĂwiÚcony konsu- mentom usïug, a rozdziaï 7. koncentruje siÚ na wzorcach zwiÈzanych z kompozycjÈ i integracjÈ usïug. Definicja SOA z rozdziaïu 1. mówi, ĝe „kaĝda usïuga ujawnia okreĂlone procesy i zachowania poprzez kontrakty, które skïadajÈ siÚ z komunikatów w wykrywalnych adresach”. To znacznie upraszcza interakcje usïug — po prostu wysyïasz komunikat i otrzymujesz komunikat zwrotny, prawda? Dlaczego wiÚc musimy poĂwiÚciÊ inte- rakcjom usïug caïy rozdziaï, a nawet dwa? Kup książkęPoleć książkę 142 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Rysunek 5.1. Rozdziaá ten koncentruje siĊ na áączeniu usáug z interfejsami uĪytkowników. To pierwszy z rozdziaáów tej ksiąĪki poĞwiĊcony konsumentom usáug To prawda, ĝe komunikaty sÈ podstawowym budulcem interakcji usïug, ale istnieje wiele sposobów interakcji wykorzystujÈcych ten budulec. Ludzie podobnie uĝywajÈ zdañ jako budulca dla komunikacji i interakcji. Kiedy kontaktujesz siÚ z przedstawicielem handlowym, moĝliwych jest kilka interakcji: Q Moĝesz zadaÊ okreĂlone pytanie i uzyskaÊ odpowiedě (wzorzec ¿Èdanie/Odpowiedě z podrozdziaïu 5.1). Q Moĝesz zostawiÊ wiadomoĂÊ z zapytaniem i swoim numerem telefonu, a przedstawiciel handlowy oddzwoni do Ciebie póěniej (wzorzec ¿Èdanie/Reakcja z podrozdziaïu 5.2). Q Przedstawiciel handlowy moĝe zadzwoniÊ do Ciebie i poinformowaÊ CiÚ o nowych produktach (wzorzec Odwrócenie Komunikacji z podrozdziaïu 5.3). Q Moĝesz prowadziÊ obszernÈ korespondencjÚ z przedstawicielem handlowym, wymieniajÈc wiadomoĂci e-mail, zanim Twój problem zostanie rozwiÈzany (wzorzec Saga z podrozdziaïu 5.4). To, co dotyczy prawdziwego ĝycia, sprawdza siÚ równieĝ w przypadku usïug. W przeciwieñstwie do wiÚkszoĂci innych wzorców z tej ksiÈĝki, te wzorce pod- stawowych interakcji istniaïy, zanim nawet wymyĂlono SOA — zadaniem tego roz- dziaïu jest przyjrzenie siÚ tym wzorcom interakcji z perspektywy SOA i atrybutów jakoĂciowych tej architektury. Zobaczymy, co sprawia, ĝe wzorzec interakcji, taki jak komunikacja asynchroniczna, dziaïa zgodnie z zasadami SOA i zachowuje korzy- Ăci SOA. W tym rozdziale zajmiemy siÚ nastÚpujÈcymi wzorcami: Q ¿Èdanie/Odpowiedě (ang. Request/Reply) — Umoĝliwia konsumentowi usïug prostÈ interakcjÚ z usïugÈ. Q ¿Èdanie/Reakcja (ang. Request/Reaction) — Tymczasowo oddziela ĝÈdanie od konsumenta usïug oraz odpowiedě od usïugi. Kup książkęPoleć książkę 5.1. Wzorzec ¿Èdanie/Odpowiedě 143 Q Odwrócenie Komunikacji (ang. Inversion of Communications) — Obsïuguje zdarzenia biznesowe w SOA. Q Saga (ang. Saga) — Umoĝliwia osiÈgniÚcie konsensusu rozproszonego pomiÚdzy usïugami bez stosowania transakcji. Zacznijmy od najbardziej podstawowej formy komunikacji — komunikacji synchro- nicznej. Wzorzec nazywa siÚ ¿Èdanie/Odpowiedě. 5.1. Wzorzec ĩądanie/OdpowiedĨ ¿Èdanie/Odpowiedě jest prawdopodobnie najstarszym i najlepiej opisanym wzor- cem w naukach komputerowych. Gregor Hohpe i Bobby Woolf oferujÈ dobry opis wzorca ¿Èdanie/Odpowiedě w swojej ksiÈĝce Enterprise Integration Patterns (Addison-Wesley Professional, 2003), gdzie okreĂlajÈ ten wzorzec jako odpowiada- jÈcy na pytanie: „Kiedy aplikacja wysyïa komunikat, w jaki sposób moĝe otrzymaÊ odpowiedě od odbiorcy?”. Koncepcja wzorca ¿Èdanie/Odpowiedě w SOA nie róĝni siÚ znacznie. Powodem do omówienia danego wzorca w tej ksiÈĝce jest jednak to, ĝe nadal istnieje kilka kwestii, na które warto zwróciÊ uwagÚ, korzystajÈc z niego w SOA. WspomnÚ o nich w kontekĂcie omawiania rozwiÈzania. Najpierw przyjrzyjmy siÚ problemowi. PROBLEM Podczas opracowywania jednowarstwowego oprogramowania, które dziaïa wewnÈtrz jednego procesu i pojedynczej przestrzeni pamiÚci, stosunkowo ïatwo jest uzyskaÊ interakcjÚ komponentów. Kiedy komponent ĝÈdajÈcy potrzebuje czegoĂ od innego komponentu (podmiotu odpowiadajÈcego), moĝe ïatwo uzyskaÊ referencjÚ do tego komponentu, np. poprzez jego instancjonowanie. Podmiot ĝÈdajÈcy moĝe wtedy wywoïaÊ metodÚ w komponencie odpowiadajÈcym i otrzymaÊ odpowiedě jako refe- rencjÚ lub adres pamiÚci, pod którym ta odpowiedě siÚ znajduje. W SOA, które jest stylem architektonicznym systemów rozproszonych, drugi komponent zazwyczaj znajduje siÚ w innej przestrzeni pamiÚci i najprawdopo- dobniej na innej maszynie — patrz rysunek 5.2. UWAGA Zdalne wywoïania zostaïy technologicznie rozwiÈzane przed powsta- niem SOA, ale byïy to rozwiÈzania przeznaczone dla innych stylów architek- tonicznych. WiÚkszoĂÊ z tych technologii moĝe byÊ równieĝ wykorzystana w SOA — róĝnicÚ stanowi sposób ich wykorzystania. Wrócimy do tego w dalszej czÚĂci rozdziaïu. ? PierwszÈ rzeczÈ, jakÈ musimy zrobiÊ, jest znalezienie sposobu na interakcjÚ usïug z ich konsumentami. Jak moĪesz umoĪliwiü konsumentom usáug prostą interakcjĊ z usáugą? W tym rozdziale zostaïo uszczegóïowionych kilka alternatywnych sposobów inte- rakcji z usïugami: asynchroniczne ¿Èdanie/Odpowiedě (wzorzec ¿Èdanie/Reakcja), Kup książkęPoleć książkę 144 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Rysunek 5.2. Obiekty zinstancjonowane w obrĊbie jednego procesu w porównaniu z usáugami. W przypadku obiektu lokalnego wysáanie Īądania z jednego komponentu do drugiego jest proste — otrzymujesz referencjĊ do tego drugiego komponentu i wykonujesz Īądanie, wywoáując go. W SOA Īądający i konsument nie znajdują siĊ w jednej przestrzeni adresowej. Prawdopodobnie nie znajdują siĊ równieĪ na jednym komputerze, a moĪe są nawet w innej sieci LAN. Wykonanie Īądania w tych warunkach jest znacznie bardziej skomplikowane 9 dïugotrwaïe interakcje (wzorzec Saga) lub zdarzenia (wzorzec Odwrócenie Komu- nikacji). SÈ one bardziej wydajne niĝ wzorzec ¿Èdanie/Odpowiedě, ale ma to równieĝ swojÈ cenÚ — sÈ one bardziej zïoĝone od wzorca ¿Èdanie/Odpowiedě zarówno w zakresie implementacji, jak i wsparcia. ROZWIĄZANIE Wyrafinowanie bywa uzasadnione, ale czasem potrzebna jest prosta synchroniczna interakcja pomiÚdzy dwoma zdalnymi komponentami. WyĞlij Īądanie od konsumenta, obsáuĪ Īądanie synchronicznie i wyĞlij z usáugi komunikat z odpowiedzią. Zarówno Īądanie, jak i odpowiedĨ naleĪą do usáugi odbierającej. Przedstawiony na rysunku 5.3 wzorzec ¿Èdanie/Odpowiedě jest najbardziej pod- stawowym wzorcem interakcji, nie wymaga wiÚc ĝadnych specjalnych komponen- tów. Potrzebujesz jedynie schematu logicznego, który akceptuje ĝÈdania, przetwarza je synchronicznie i zwraca odpowiedě lub wynik. JednÈ rzeczÈ, na którÈ naleĝy zwróciÊ uwagÚ, jest to, ĝe zarówno komunikat ĝÈdania, jak i komunikat z odpo- wiedziÈ naleĝÈ do kontraktu usïugi, a nie konsumenta usïug (co jest typowym bïÚdem u nowicjuszy w dziedzinie SOA). Wzorzec ¿Èdanie/Odpowiedě obejmuje jedynie wymianÚ komunikatów. Kom- pletna interakcja wymaga równieĝ infrastruktury komunikacyjnej. MógïbyĂ w tym Kup książkęPoleć książkę 5.1. Wzorzec ¿Èdanie/Odpowiedě 145 Rysunek 5.3. Wzorzec ĩądanie/OdpowiedĨ definiuje komunikaty ĪądaĔ i odpowiedzi w kontrakcie usáugi. Kiedy usáuga otrzymuje Īądanie w odpowiednim formacie, przetwarza je synchronicznie i zwraca konsumentowi usáug komunikat z odpowiedzią celu wykorzystaÊ wzorzec Magistrala Usïugi (omówiony w rozdziale 7.), który obsïu- guje udostÚpnianie usïug w osiÈgalnych (lub nawet wykrywalnych) punktach koñ- cowych, a takĝe routuje odpowiedzi. Role ĝÈdania i odpowiedzi sÈ raczej oczywiste. ¿Èdanie przechowuje zamiar lub zadanie, które usïuga ma wykonaÊ, a takĝe dane wejĂciowe niezbÚdne do jego wykonania. Odpowiedě zawiera wynik wykonania zadania. Gïównym problemem ze stylem interakcji ¿Èdanie/Odpowiedě jest to, ĝe podej- rzanie przypomina on zdalne wywoïania procedur (RPC) — DCOM/CORBA, czyli rozproszone modele obiektowe. PowinieneĂ byÊ ostroĝny przy modelowaniu kon- traktów usïug z nastawieniem na RPC — moĝe mieÊ to niekorzystny wpïyw na Twoje systemy SOA, poczynajÈc od niskiej wydajnoĂci, aĝ po caïkowite zaprzecze- nie tej architektury. Zamiast stosowania podejĂcia RPC moĝesz spróbowaÊ mode- lowaÊ swoje kontrakty metodÈ dokumentowo-centrycznÈ. Czym, u licha, jest „podej- Ăcie dokumentowo-centryczne”? Dobre pytanie. W skrócie podejĂcie dokumentowo-centryczne (ang. document-centric) oznacza, ĝe komunikat zawiera wystarczajÈcÈ iloĂÊ informacji, aby reprezentowaÊ kompletnÈ jednostkÚ pracy, oraz nie instruuje usïugi, w jaki sposób ma ona obsïugiwaÊ komu- nikat. Dla kontrastu wywoïania RPC majÈ tendencjÚ do bycia zorientowanymi na polecenia i nastawionymi na wysyïanie tylko parametrów niezbÚdnych do wykonania dziaïania. MajÈ one pewne stanowe oczekiwania ze strony usïugi oraz domniemane oczekiwania odnoĂnie tego, co ma staÊ siÚ po stronie konsumenta. Dokumentowo- centryczne komunikaty nie robiÈ takich zaïoĝeñ. Posiadanie kompletnej jednostki pracy oznacza, ĝe usïuga posiada wystarczajÈcÈ iloĂÊ informacji lub kontekstu w komu- nikacie, aby zrozumieÊ wymagany stan. Oznacza to równieĝ, ĝe komunikaty doku- mentowo-centryczne sÈ zazwyczaj bardziej gruboziarniste niĝ ich odpowiedniki RPC. UWAGA Jest jeszcze trzeci typ komunikatów, zwany komunikatami zdarzeñ (ang. event messages). Zajmiemy siÚ nim w kontekĂcie wzorca Odwrócenie Komunikacji w podrozdziale 5.3. W tabeli 5.1 przedstawiono trzy sposoby na to, aby dokumentowo-centryczne komunikaty mogïy zawieraÊ wiÚcej kontekstu. Kup książkęPoleć książkę 146 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Tabela 5.1. Opcje dostarczenia kontekstu w komunikacie dokumentowo-centrycznym Kontekst Historia PrzyszáoĞü Kompletna przyszáoĞü WyjaĞnienie Komunikaty mogą zawieraü interakcje do okreĞlonego momentu, podobnie jak okruszki chleba w bajce o Jasiu i Maágosi. JeĞli w scenariuszu zamawiania pierwszym krokiem byáo pobranie danych konsumenta, a bieĪącym krokiem jest záoĪenie zamówienia (kaĪda czynnoĞü wykonywana przez inną usáugĊ), to komunikat przesyáany do usáugi zamawiania zawieraáby informacje o konsumencie Komunikat moĪe zawieraü opcje, z których konsument moĪe skorzystaü w celu wypeánienia interakcji. JeĞli w scenariuszu zamawiania poprzednim krokiem byáo zarezerwowanie zamówienia (patrz wzorzec Rezerwacja w rozdziale 6.), komunikat zwrotny mógáby zawieraü informacje wymagane do potwierdzenia rezerwacji Innym sposobem zapewnienia kontekstu jest, aby format komunikatu zawieraá kompletne dane szczegóáowe niezbĊdne do przeprowadzenia interakcji. W przykáadzie zamawiania oznaczaáoby to, Īe komunikat posiadaáby szkielet do obsáugi szczegóáów zamówienia i kwestii z nim związanych, a zaangaĪowane strony wypeániaáyby puste pola wraz z postĊpowaniem interakcji Naleĝy zwróciÊ uwagÚ na dwie kwestie. Komunikaty mogÈ ïÈczyÊ kilka typów kontekstu, a ten sam dokument, w celu umoĝliwienia zakoñczenia procesu bizneso- wego, moĝe byÊ wymieniany wielokrotnie pomiÚdzy usïugÈ i jej konsumentem, np. z uwagi na dodawanie na tej drodze róĝnych szczegóïów. MAPOWANIE TECHNOLOGII Mapowanie technologii dla wzorca ¿Èdanie/Odpowiedě jest raczej trywialne. Kaĝda z przychodzÈcych mi do gïowy technologii umoĝliwia implementacjÚ tego wzorca w tej czy innej formie. WiÚkszoĂÊ technologii nadzwyczaj ïatwo pozwala udostÚpniaÊ zdalnie obiekty, co zachÚca do zastosowania interakcji w stylu RPC. Interakcje dokumentowo-cen- tryczne sÈ znacznie trudniejsze do wprowadzenia. Listing 5.1 przedstawia fragment kodu z kreatora nowego projektu dla biblioteki usïug WFC w Visual Studio 2010 Microsoftu. Przykïadowy kod pokazuje, jak wziÈÊ prostÈ klasÚ i udostÚpniÊ jej metody jako usïugi sieciowe. Listing 5.1. Kod z kreatora nowego projektu sáuĪący tworzeniu usáugi WFC namespace WCFServiceLibrary1 { [ServiceContract()] public interface IService1 { [OperationContract] string MyOperation1(string myValue); [OperationContract] string MyOperation2(DataContract1 dataContrac tValue); } UdostĊpnia metodĊ jako usáugĊ sieciową public class service1 : IService1 { public string MyOperation1(string myValue) { Kup książkęPoleć książkę 5.1. Wzorzec ¿Èdanie/Odpowiedě 147 return Hello: + myValue; } public string MyOperation2(DataContract1 dataContractValue) { return Hello: + dataContractValue.FirstName; } } Definiuje podstawowy dokument (brakujące áącza do powiązanych danych) [DataContract] public class DataContract1 { string firstName; string lastName; Akceptuje dokument (kontrakt danych) jako parametr Obsáuguje dokument na sposób RPC (nie zwraca dokumentu) [DataMember] public string FirstName { get { return firstName; } set { firstName = value; } } [DataMember] public string LastName { get { return lastName; } set { lastName = value; } } } Na pierwszy rzut oka ten kod moĝe wyglÈdaÊ jak dobry przykïad wzorca ¿Èda- nie/Odpowiedě (moĝe z wyjÈtkiem nazewnictwa). Konsument usïugi moĝe wysïaÊ komunikat MyOperation1 z zaïÈczonym ciÈgiem znaków i otrzymaÊ jako odpowiedě „Hello:” doïÈczone do tego ciÈgu. Jednak MyOperation1 to klasyczna implementacja interakcji RPC. Sytuacja jest nieco lepsza w przypadku drugiej metody (MyOperation2). Tutaj prosty dokument jest przekazywany do metody. Jednak ten przykïadowy kod obsïu- guje dany dokument równieĝ na sposób RPC i nie zwraca dokumentu w ramach odpowiedzi. Takie podejĂcie nie jest unikatowe dla platformy .NET — kolejnym przykïadem moĝe byÊ styl REST. O ile zasady REST promujÈ podejĂcie dokumentowo-cen- tryczne, to podstawowymi poleceniami HTTP sÈ PUT, GET, POST i DELETE, które ponow- nie kierujÈ nowicjuszy na tory interfejsów CRUD. Dokumentowo zorientowane podejĂcie skutkuje bogatszymi komunikatami, które zawierajÈ pewien kontekst, jeĂli nawet nie caïy. Przyjrzyj siÚ fragmentowi kodu XML z listingu 5.2. Listing 5.2. Przykáadowa odpowiedĨ dokumentowo-centryczna feed xmlns= http://www.w3.org/2005/Atom xmlns:gd= http://schemas.google.com/g/2005 id http://www.google.com/calendar/feeds/johndoe@gmail.com/ ´private-0c1e3facdd1a4252aad07effeb7d68cc9/full /id updated 2007-06-29T19:22:12.000Z /updated Kup książkęPoleć książkę 148 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów title type= text John Doe /title link rel= http://schemas.google.com/g/2005#feed type= application/atom+xml href= http://www.google.com/calendar/feeds/johndoe@gmail.com/ ´private-0c1e3facdd1a4252aad07effeb7d68cc9/full /link link rel= self type= application/atom+xml href= http://www.google.com/calendar/feeds/johndoe@gmail.com/ ´private-0c1e3facdd1a4252aad07effeb7d68cc9/full /link author name John Doe /name email johndoe@gmail.com /email /author generator version= 1.0 uri= http://www.google.com/calendar/ CL2 /generator gd:where valueString= Neverneverland /gd:where entry id http://www.google.com/calendar/feeds/johndoe@gmail.com/ ´private-0c1e3facdd1a4252aad07effeb7d68cc9/full/ ´aaBxcnNqbW9tcTJnaTT5cnMybmEwaW04bXMgbWFyY2guam9AZ21haWwuY29t /id published 2007-06-30T22:00:00.000Z /published updated 2007-06-28T015:33:31.000Z /updated category scheme= http://schemas.google.com/g/2005#kind term= http://schemas.google.com/g/2007#event /category title type= text Writing SOA Patterns /title content type= text shhh… /content link rel= alternate type= text/html href= http://www.google.com/calendar/ ´event?eid=aaBxcnNqbW9tcTJnaTT5cnMybmEwaW04bXMgbWFyY2guam9AZ21haWwuY29t title= alternate /link link rel= self type= application/atom+xml href= http://www.google.com/calendar/feeds/johndoe@gmail.com/ ´private-0c1e3facdd1a4252aad07effeb7d68cc9/full/ ´aaBxcnNqbW9tcTJnaTT5cnMybmEwaW04bXMgbWFyY2guam9AZ21haWwuY29t /link author name John Doe /name email johndoe@gmail.com /email /author gd:transparency value= http://schemas.google.com/g/2005#event.opaque /gd:transparency gd:eventStatus value= http://schemas.google.com/g/2005#event.confirmed /gd:eventStatus gd:comments gd:feedLink href= http://www.google.com/calendar/feeds/johndoe@gmail.com/ ´private-0c1e3facdd1a4252aad07effeb7d68cc9/full/ ´aaBxcnNqbW9tcTJnaTT5cnMybmEwaW04bXMgbWFyY2guam9AZ21haWwuY29t/comments/ /gd:feedLink /gd:comments gd:when startTime= 2006-08-14T20:30:00.000Z endTime= 2012-03-28T22:30:00.000Z /gd:when gd:where /gd:where /entry /feed Kup książkęPoleć książkę 5.2. Wzorzec ¿Èdanie/Reakcja 149 Ten listing pokazuje wynik ĝÈdania peïnego kalendarza z usïugi Google Kalendarz. Poza szczegóïami dotyczÈcymi kalendarza (tytuï, data aktualizacji, nazwa wïaĂciciela itd.) otrzymujesz wszystkie zestawienia ze wszystkimi szczegóïami, a takĝe wskaěnik do pobrania kaĝdego wpisu kalendarza bezpoĂrednio. Wynik wykorzystuje protokóï Google GData, który z kolei jest oparty na protokole APP (ang. Atom Publishing Protocol). ZwróÊ uwagÚ, ĝe kontrakt dla akceptowania tego dokumentu XML jest równieĝ prostszy niĝ ten z listingu 5.1, poniewaĝ potrzeba jedynie obsïuĝyÊ pojedyn- czy parametr XML. Konsumenci nie sÈ przywiÈzani do okreĂlonych informacji, które mogÈ zmieniaÊ siÚ z czasem. PodsumowujÈc, wzorzec ¿Èdanie/Odpowiedě jest obsïugiwany przez wszystkie technologie umoĝliwiajÈce zdalnÈ komunikacjÚ. Wybór pomiÚdzy RPC a podejĂciem dokumentowo-centrycznym jest decyzjÈ projektowÈ, która nie jest determinowana przez technologiÚ. Musi ona zostaÊ podjÚta przez programistów lub architektów danego rozwiÈzania. ATRYBUTY JAKOĝCIOWE Wzorzec ¿Èdanie/Odpowiedě jest prostym wzorcem ïÈczÈcym konsumenta usïug z usïugÈ, z którÈ chce on wejĂÊ w interakcjÚ. BÚdÈc wzorcem podstawowym, nie rozwiÈzuje wiÚkszoĂci kwestii zwiÈzanych z atrybutami jakoĂciowymi, z wyjÈtkiem zapewnienia wymaganej funkcjonalnoĂci (umoĝliwienia interakcji pomiÚdzy konsu- mentem a usïugÈ). Jednym z atrybutów jakoĂciowych, który moĝe byÊ istotny, jest prostota. Poniewaĝ ¿Èdanie/Odpowiedě jest prostym wzorcem, jest ïatwy w implementacji i zapew- nieniu wsparcia, dziÚki czemu pomaga zmniejszyÊ stopieñ zïoĝonoĂci rozwiÈzania. Tabela 5.2 zawiera przykïadowe scenariusze, w których moĝna rozwaĝyÊ zasto- sowanie wzorca ¿Èdanie/Odpowiedě. Tabela 5.2. Atrybuty jakoĞciowe wzorca ĩądanie/OdpowiedĨ i przykáadowe scenariusze Atrybut jakoĞciowy Konkretny atrybut Przykáadowy scenariusz Czas opracowywania àatwy rozwój TestowalnoĞü Pokrycie Podczas fazy rozwoju udostĊpnianie nowych funkcjonalnoĞci (przygotowanych uprzednio) w usáudze nie powinno zająü wiĊcej niĪ póá dnia, wliczając implementacjĊ i testy Podczas fazy rozwoju kaĪda funkcjonalnoĞü usáugi powinna mieü 100-procentowe pokrycie testowe Jak wspomniano wczeĂniej, ¿Èdanie/Odpowiedě jest podstawowym synchronicz- nym wzorcem komunikacyjnym. NastÚpny wzorzec interakcji koncentruje siÚ na implementacji komunikacji asynchronicznej w ramach ograniczeñ i zasad SOA. 5.2. Wzorzec ĩądanie/Reakcja Komunikacja synchroniczna opisana w kontekĂcie wzorca ¿Èdanie/Odpowiedě (w poprzednim podrozdziale) jest bardzo istotna, ale nie jest wystarczajÈca. Syn- chroniczna natura wzorca ¿Èdanie/Odpowiedě oznacza, ĝe konsument usïug musi oczekiwaÊ, aĝ usïuga zakoñczy przetwarzanie jego ĝÈdania, zanim bÚdzie mógï Kup książkęPoleć książkę 150 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów kontynuowaÊ swoje dziaïanie. SÈ sytuacje, w których konsument usïug nie chce cze- kaÊ lub nie moĝe sobie na to pozwoliÊ, jednak nadal jest zainteresowany otrzyma- niem odpowiedzi, kiedy tylko bÚdzie ona dostÚpna. Masïo maĂlane? Przyjrzyjmy siÚ konkretnemu przykïadowi, abym mógï to lepiej wyjaĂniÊ. PROBLEM We wspóïczesnych systemach kontroli granic, kiedy podróĝnik podchodzi do urzÚd- nika imigracyjnego, urzÚdnik sprawdza w systemie szczegóïowe informacje na temat danej osoby (wpisuje numer seryjny paszportu itd.), a nastÚpnie przeglÈda paszport i porównuje zdjÚcie. W ciÈgu kilku ostatnich lat pañstwa na caïym Ăwiecie zaczÚïy przechodziÊ na systemy e-paszportów. E-paszporty zawierajÈ kilka elemen- tów, w tym chip RFID, odczytywalny maszynowo kod oraz kilka próbek biometrycz- nych (zazwyczaj zdjÚcie twarzy oraz odciski palców). Na rysunku 5.4 przedstawiono wysokopoziomowy przeglÈd schematu przepïywu dla wydawania e-paszportów. Rysunek 5.4. Proces rejestracji. Kiedy interfejs uĪytkownika (UI) wysyáa do usáugi e-paszportu zapytanie o wydanie paszportu, usáuga, aby speániü to Īądanie, musi wspóápracowaü z kilkoma innymi usáugami Kup książkęPoleć książkę 5.2. Wzorzec ¿Èdanie/Reakcja 151 Jak widaÊ, jednym z etapów schematu przepïywu jest rejestrowanie osoby w bazie danych biometrii (która jest elementem usïugi biometrycznej). Chociaĝ nie wynika to z samego schematu interakcji, zadanie rejestracji moĝe zajÈÊ sporo czasu, ponie- waĝ usïuga biometryczna wewnÚtrznie sprawdza, czy istniejÈ duplikaty. Jest to niezbÚdne w celu zapewnienia integralnoĂci danych i unikniÚcia bïÚdów oraz celo- wych zmian toĝsamoĂci. Ten etap polega na porównywaniu kaĝdej próbki (np. kaĝ- dej twarzy) z kaĝdÈ pozostaïÈ próbkÈ znajdujÈcÈ siÚ juĝ w bazie danych, co moĝe stanowiÊ setki milionów rekordów (populacja caïego kraju). Wykonywanie tego typu ĝÈdañ przy zastosowaniu wzorca interakcji ¿Èda- nie/Odpowiedě jest problematyczne, poniewaĝ czas oczekiwania pomiÚdzy ĝÈdaniem a odpowiedziÈ jest zbyt dïugi. Moĝe byÊ nawet jeszcze gorzej, jeĂli zdecydujesz siÚ na podwójne sprawdzanie w trakcie zautomatyzowanych nocnych procesów kon- serwacyjnych. Taka sytuacja nie jest unikatowa dla systemów e-paszportów. Podobne sytuacje zdarzajÈ siÚ równieĝ w innych systemach. Przykïadowo, przy zakupie udziaïów w funduszu powierniczym transakcja nie jest przeprowadzana natychmiastowo, ale prawdopodobnie bÚdziesz chciaï wiedzieÊ, kiedy zostanie zakoñczona. Innym przykïadem jest skierowanie ĝÈdania do systemu planowania podróĝy, ĝeby znalazï Ci najlepszÈ ofertÚ na kolejne wakacje. Oto problem: ? Jak moĪesz tymczasowo oddzieliü Īądanie od konsumenta usáug oraz odpowiedĨ od usáugi? JednÈ z opcji jest rozwiÈzanie kwestii tymczasowych powiÈzañ po stronie klienta. W tym celu uruchamiany jest nowy wÈtek przed wysïaniem ĝÈdania do usïugi. NastÚpnie wÈtek oczekuje na odpowiedě, podczas gdy reszta interfejsu uĝytkownika pozostaje w stanie reagowania. Platforma .NET posiada komponent zwany Backgro- undWorker, który dokonuje tej separacji i pozwala interfejsowi uĝytkownika na dysponowanie dïugotrwaïych zadañ bez blokowania swojego wÈtku. To rozwiÈzanie ma swoje wady. Po pierwsze, „oczekiwanie” nie jest odporne — jeĂli konsument usïug bÚdzie miaï awariÚ, odpowiedě zostanie utracona i nie bÚdzie dostÚpna, gdy konsument odzyska sprawnoĂÊ. Ponadto wÈtek wykorzystuje zasoby konsumenta — co siÚ stanie, jeĂli przetwarzanie ĝÈdania bÚdzie trwaïo kilka godzin lub dni? Dochodzi jeszcze kwestia odpowiedzialnoĂci. To usïuga ma do wykonania zadanie, które jest czasochïonne — odpowiedzialnoĂciÈ usïugi powinno byÊ rozwiÈ- zanie tego problemu i nieprzerzucanie go na konsumentów. Innym podejĂciem rozwiÈzujÈcym kwestiÚ tymczasowego oddzielenia jest obej- Ăcie tego problemu poprzez podzielenie interakcji. Przykïadowo, kiedy zamawiasz towar online, nie siedzisz, czekajÈc, aĝ system wyĂle Ci ten towar. W zamian system powiadamia CiÚ, ĝe towar zostaï zamówiony. Rejestracja zamówienia zajmuje znacz- nie mniej czasu niĝ jego realizacja. Minusem jest to, ĝe nie bÚdziesz wiedziaï, czy towar zostaï wysïany, jeĂli raz na jakiĂ czas nie sprawdzisz statusu zamówienia. Podobnie jak w poprzednim podejĂciu na Tobie jako na konsumencie usïug spoczywa w tym przypadku odpowiedzialnoĂÊ za rekompensowanie niedociÈgniÚÊ usïugi. Kup książkęPoleć książkę 152 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów IstniejÈ rozwiÈzania w zakresie interakcji, które obsïugujÈ zïoĝone interakcje. Naleĝy do nich wzorzec Saga (omówiony w podrozdziale 5.4). Implementacja wzorca Saga rozwiÈĝe ten problem, ale to jak strzelaÊ z armaty do wróbli. Jest to nadmiar Ărodków, kiedy potrzebujesz jedynie opóěnionej odpowiedzi. ROZWIĄZANIE Kiedy zastosowanie wzorca Saga jest przesadÈ, sprawdza siÚ zïamanie integracji. Uderza to jednak w konsumentów usïug i lepiej unikaÊ integracji po stronie klienta z powodu jej zïych skutków. Tak naprawdÚ potrzebujesz jakoĂ zaimplementowaÊ komunikacjÚ asynchronicznÈ w SOA w moĝliwie jak najprostszy sposób. Oto co musisz zrobiÊ: 9 Zastosuj wzorzec ĩądanie/Reakcja i zaimplementuj komunikacjĊ asynchroniczną pomiĊdzy konsumentami usáug a usáugą. Zaimplementuj wymianĊ komunikatów w postaci dwóch komunikatów jednokierunkowych — Īądanie ze strony konsumenta i odpowiedĨ ze strony usáugi. Koncepcja wzorca ¿Èdanie/Reakcja, przedstawionego na rysunku 5.5, zakïada posia- danie dwóch odrÚbnych interakcji pomiÚdzy konsumentem usïug a usïugÈ. Pierwsza interakcja wysyïa ĝÈdanie do serwera, który moĝe zwróciÊ potwierdzenie odbioru, bilet lub oszacowaÊ czas zakoñczenia zlecenia. Po zakoñczeniu przetwarzania usïuga musi zainicjowaÊ interakcjÚ z konsumentem usïug i wysïaÊ mu odpowiedě lub reakcjÚ. Rysunek 5.5. Wzorzec ĩądanie/OdpowiedĨ definiuje komunikaty Īądania i odpowiedzi w kontrakcie usáugi. Kiedy usáuga otrzymuje Īądanie, przetwarza je i przygotowuje reakcjĊ. Kiedy reakcja jest gotowa, usáuga odsyáa Īądanie do konsumenta UWAGA Usïuga musi posiadaÊ informacje, gdzie zwróciÊ odpowiedě — zaj- miemy siÚ tym póěniej. Wzorzec ¿Èdanie/Reakcja jest bardziej zgodny z podstawowÈ przesïankÈ wymiany komunikatów, poniewaĝ znosi powiÈzania czasowe. Dla porównania wzorzec ¿Èda- nie/Odpowiedě jest bardziej zgodny z RPC. Na rysunku 5.6 przedstawiono zastosowanie wzorca ¿Èdanie/Reakcja dla usïugi biometrycznej. Teraz kiedy usïuga biometryczna otrzymuje komunikat rejestracji, reaguje komunikatem „rejestrowanie” informujÈcym klienta, ĝe ĝÈdanie zostaïo odebrane. Po zakoñczeniu procesu rejestrowania, z powodzeniem lub z bïÚdem, przygotowywana jest odpowiedě z rekordami rejestracji, która wysyïana jest do klienta. Kup książkęPoleć książkę 5.2. Wzorzec ¿Èdanie/Reakcja 153 UWAGA W scenariuszu przedstawionym na rysunku 5.6 sensowne byïoby zastosowanie wzorca Saga (omówionego w podrozdziale 5.4) do wycofywania pozostaïych usïug, jeĂli sprawdzanie przez usïugÚ biometrycznÈ zakoñczyïoby siÚ znalezieniem duplikatu toĝsamoĂci. Rysunek 5.6. Proces wydawania paszportów wykorzystujący wzorzec ĩądanie/Reakcja. Teraz usáuga biometryczna zwraca dwa komunikaty. Najpierw zwraca potwierdzenie, Īe komunikat jest przetwarzany, a nastĊpnie po zakoĔczeniu przetwarzania zwraca status Wzorzec ¿Èdanie/Reakcja jest wykorzystany we wzorcu Oddzielone Wywoïanie (omówionym w rozdziale 2.). Róĝnica pomiÚdzy tymi dwoma wzorcami polega na tym, ĝe ¿Èdanie/Reakcja oddziela odpowiedě od ĝÈdania, podczas gdy Oddzielone Wywoïanie oddziela takĝe przetwarzanie komunikatu. Semantyka interakcji wzorca ¿Èdanie/Reakcja jest ograniczona. JeĂli scena- riusz systemu e-paszportowego uwzglÚdniaïby moĝliwoĂÊ anulowania rejestracji (np. w przypadku bïÚdu Ăwiadczenia usïug RFID), problematyczne byïoby skoor- dynowanie tego z grupÈ ĝÈdañ i reakcji. W takich dïugotrwaïych interakcjach moĝna rozwaĝyÊ zastosowanie bardziej zaawansowanych wzorców, takich jak wzorzec Saga opisany w podrozdziale 5.4. Kup książkęPoleć książkę 154 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Wzorzec ¿Èdanie/Reakcja oferuje wiÚkszÈ elastycznoĂÊ niĝ ¿Èdanie/Odpowiedě, ale ma to swojÈ cenÚ. ¿Èdanie/Reakcja jest bardziej skomplikowanym wzorcem niĝ ¿Èdanie/Odpowiedě i wymaga wiÚcej pracy po stronie usïugi (lub komponentu brzegowego). Przyjrzyjmy siÚ niektórym szczegóïom implementacji, o które naleĝy zadbaÊ. MAPOWANIE TECHNOLOGII Najlepszym sposobem implementacji wzorca interakcji ¿Èdanie/Reakcja jest zasto- sowanie dwóch jednokierunkowych komunikatów. JeĂli korzystasz z usïug siecio- wych, bÚdzie to oznaczaÊ dwa kanaïy HTTP. JeĂli stosujesz komunikaty, bÚdziesz potrzebowaï kolejki (punktu koñcowego) dla kaĝdej z zainteresowanych stron. PierwszÈ przeszkodÈ jest czasowe oddzielenie. Poniewaĝ ĝÈdanie i reakcja (odpowiedě) sÈ oddzielone w czasie, pozostaïe komunikaty mogÈ znaleěÊ siÚ pomiÚ- dzy nimi. Oznacza to, ĝe musisz zapewniÊ sposób uzyskiwania przez usïugÚ infor- macji, gdzie wysïaÊ reakcjÚ. Oznacza to takĝe, ĝe zarówno usïuga, jak i konsument usïug potrzebujÈ sposobu korelacji komunikatów ĝÈdania i reakcji — wiÚcej szcze- góïów na ten temat znajdziesz w ramce „Komunikaty skorelowane”. Zarówno Java, jak i .NET oferujÈ rozwiÈzania z zakresu komunikatów jedno- kierunkowych. Biblioteka Javy Apache Axis2 oferuje nawet gotowÈ infrastrukturÚ do implementacji kompletnego wzorca ¿Èdanie/Reakcja. Listing 5.3 przedstawia kod po stronie klienta wymagany do wysyïania komunikatów asynchronicznych. Z punktu widzenia architektonicznego reakcja jest komunikatem wysyïanym przez usïugÚ. Jednak z punktu widzenia implementacji moĝe ona byÊ równieĝ zaimplementowana w formie pobierania jej przez konsumenta usïug. Komunikaty skorelowane Jedno z wyzwaĔ dotyczących asynchronicznej wymiany komunikatów wynika z faktu, Īe komunikat reakcji i Īądanie nie są bezpoĞrednio powiązane. Reakcja moĪe przycho- dziü dáugo po czasie wysáania pierwotnego Īądania. W takiej sytuacji potrzebny jest sposób identyfikacji, Īe te dwa komunikaty są powiązane. Mechanizm rozwiązujący ten problem znany jest jako identyfikator korelacji i jak wskazuje nazwa, polega on na dodaniu do komunikatów tokenu, który moĪe byü wykorzystany przez konsumentów usáug i usáugi do identyfikacji powiązanych komu- nikatów. Nie jest to bardzo odlegáe od koncepcji ciasteczek sesji w aplikacji WWW. Identyfikator korelacji moĪe zawieraü ID komunikatu, token konwersacji itd. Korelacja jest obsáugiwana przez szeroką gamĊ standardów WS-*. WS-Addressing posiada np. relacjĊ nagáówka identyfikatora komunikatu, która moĪe byü uĪyta dla okreĞlania korelacji. Kolejnym przykáadem jest WS-BPEL, który ma nawet lepsze wspar- cie dla korelacji, umoĪliwiając programistom definiowanie róĪnych zestawów korelacji wraz z zawartoĞcią tych zestawów. Listing 5.3. Wykorzystujący wzorzec ĩądanie/Reakcja kod klienta sáuĪący do wysyáania komunikatów boolean useTwoChannels = true; ... Kup książkęPoleć książkę 5.2. Wzorzec ¿Èdanie/Reakcja 155 OMElement messageBody = helper.FormatmMessage(data,type); Call msgSender = new Call(); msgSender.setTo( new EndpointReference(AddressingConstants.WSA_TO, HTTP://www.example.org/ServiceName)); msgSender.setTransportInfo(Constants.TRANSPORT_HTTP, Constants.TRANSPORT_HTTP, useTwoChannels); Callback callback = new Callback() { public void onComplete(AsyncResult result) { // tutaj naleĪy wstawiü kod do obsáugi Reakcji } public void reportError(Exception e) { // kod obsáugi báĊdów… } }; msgSender.engageModule(new Qname( addressing )); msgSender.invokeNonBlocking( MessageName , messageBody, callback); Implementacja wzorca ¿Èdanie/Reakcja na bazie wzorca ¿Èdanie/Odpowiedě nie jest zbyt skomplikowana. Na rysunku 5.7 przedstawiono kolejne etapy. Kiedy kon- sument usïug wysyïa ĝÈdanie, otrzymuje w ramach odpowiedzi adres reakcji (w tym przypadku URI). Konsument otrzymuje równieĝ token czasu okreĂlajÈcy, kiedy moĝna siÚ spodziewaÊ odpowiedzi. Po upïywie wskazanego czasu konsument wysyïa drugie ĝÈdanie do usïugi, tym razem proszÈc o odpowiedě (np. za pomocÈ pole- cenia GET). Rysunek 5.7. Implementacja wzorca ĩądanie/Reakcja na bazie wzorca ĩądanie/OdpowiedĨ. Komunikat zwrotny Īądania objaĞnia, gdzie bĊdzie moĪna znaleĨü reakcjĊ i jaki jest szacowany czas dostarczenia (ang. Estimated Time of Arrival — ETA). Po upáywie czasu ETA, jeĞli konsument usáug nie jest zajĊty, moĪe przejĞü do adresu reakcji w usáudze i samodzielnie pobraü reakcjĊ UWAGA Do Ăledzenia czasu moĝesz u konsumenta zastosowaÊ wzorzec Usïuga Aktywna omówiony w rozdziale 2. Kup książkęPoleć książkę 156 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów TÚ drogÚ (technologiÚ push zamiast pull) naleĝy wybraÊ, kiedy nie jesteĂ w stanie stworzyÊ aktywnego, niezaleĝnego punktu koñcowego po stronie konsumenta. Ponownie preferowanym podejĂciem byïoby typowe zastosowanie wzorca ¿Èda- nie/Reakcja. Jednak jeĂli nie moĝesz tego zrobiÊ, to moĝesz zaimplementowaÊ podej- Ăcie pull i nadal speïniaÊ wymogi ogólnej koncepcji wzorca, które zakïadajÈ uzy- skanie elastycznoĂci i tymczasowego oddzielenia. ATRYBUTY JAKOĝCIOWE Wspomniaïem, ĝe tymczasowe oddzielenie i elastycznoĂÊ zapewniane przez wzorzec ¿Èdanie/Reakcja sÈ gïównymi atrybutami jakoĂciowymi przemawiajÈcymi za jego zastosowaniem. Wzorzec ten moĝe byÊ równieĝ pomocny w zakresie atrybutu jako- Ăciowego wydajnoĂci. Kiedy wysyïanie komunikatu do usïugi nie blokuje konsumenta, pozwala to konsumentowi przydzielaÊ cykle CPU do innych zadañ (takich jak obsïuga ĝÈdañ z innych usïug). Porównaj to z blokujÈcym wzorcem ¿Èdanie/Odpowiedě, który przytrzymuje zasoby po stronie konsumenta, oczekujÈc na odpowiedě. Tabela 5.3 przedstawia kilka przykïadowych scenariuszy, w których wzorzec ¿Èdanie/Reakcja ma wiÚksze zastosowanie niĝ inne wzorce. Tabela 5.3. Atrybuty jakoĞciowe wzorca ĩądanie/Reakcja i przykáadowe scenariusze Atrybut jakoĞciowy Konkretny atrybut Przykáadowy scenariusz ElastycznoĞü WydajnoĞü Tymczasowe powiązania W normalnych warunkach system powinien powiadamiaü stronĊ zamawiającą o wysyáce zamówienia w ciągu dwóch godzin od nadania paczki W normalnych warunkach interfejs uĪytkownika nie bĊdzie zawieszony podczas wykonywania dáugotrwaáych operacji (takich jak wyszukiwania i przeliczanie kursu) Reagowanie Wzorzec ¿Èdanie/Odpowiedě demonstruje synchronicznÈ komunikacjÚ pomiÚ- dzy konsumentami usïug a usïugami. Z kolei wzorzec ¿Èdanie/Reakcja demonstruje komunikacjÚ asynchronicznÈ. Naleĝy sprawdziÊ, kiedy moĝliwa jest komunikacja wykorzystujÈca architekturÚ sterowanÈ zdarzeniami bez naruszenia ograniczeñ i zaïoĝeñ SOA. 5.3. Wzorzec Odwrócenie Komunikacji Wzorce ¿Èdanie/Odpowiedě i ¿Èdanie/Reakcja nastawione sÈ na interakcje, w któ- rych konsument chce uzyskaÊ informacjÚ od usïugi lub wymóc na niej jakieĂ dziaïa- nie. W tym celu konsument gotów jest ponieĂÊ koszty powiÈzañ, które sÈ niezbÚdne do uzyskania informacji o usïudze, jej funkcjonalnoĂciach oraz protokole (kontrakcie) stosowanym przez niÈ do udostÚpniania tych funkcjonalnoĂci. Co siÚ jednak stanie, kiedy potencjalny konsument nie bÚdzie wiedziaï, ĝe musi poprosiÊ usïugÚ o nowe informacje? Czy usïuga sama go powiadomi? Czy usïuga bÚdzie chciaïa ponieĂÊ koszty powiÈzañ? Kup książkęPoleć książkę 5.3. Wzorzec Odwrócenie Komunikacji 157 Chociaĝ na pozór taka sytuacja moĝe wydawaÊ siÚ maïo prawdopodobna, przyj- rzyjmy siÚ kilku przykïadom. Zobaczysz, ĝe jest to doĂÊ typowa sytuacja biznesowa, która moĝe byÊ normÈ. PROBLEM Zaïóĝmy, ĝe chcesz stworzyÊ dla linii lotniczych usïugÚ, która bÚdzie proaktywnie zajmowaÊ siÚ opóěnionymi lotami. Kiedy oczekiwane jest opóěnienie przylotu, moĝesz chcieÊ znaleěÊ nowe poïÈczenia dla pasaĝerów, którzy nie zdÈĝÈ na prze- siadkÚ, zwolniÊ ich rezerwacje w bieĝÈcych odlotach oraz dostosowaÊ parametry dla tych lotów. W tym celu musisz wspóïpracowaÊ z kilkoma usïugami — niektóre z nich bÚdÈ czÚĂciÈ Twojego systemu (np. usïuga ĂledzÈca wszystkie aktywne loty), a niektóre bÚdÈ zewnÚtrzne (np. usïugi dostarczajÈce raporty pogodowe i informacje o stanach lotnisk). Na rysunku 5.8 pokazano informacje o opóěnieniach, które moĝna uzyskaÊ od Federalnej Administracji Lotnictwa (ang. Federal Aviation Administration — FAA) w Stanach Zjednoczonych. Rysunek 5.8. Informacje o opóĨnieniach przylotów i odlotów dostarczane przez FAA (http://www.fly.faa.gov/flyfaa/usmap.jsp). MoĪe to byü Ĩródáo informacji dla systemu kontroli ruchu lotniczego Na rysunku 5.9 przedstawiono usïugÚ „Opóěnienia” wraz z kilkoma usïugami, z których ona korzysta. UWAGA JeĂli poszukasz w internecie zdarzeñ biznesowych, zauwaĝysz, ĝe przykïad linii lotniczych jest caïkiem popularny, ale jest teĝ wiele innych bardziej praktycznych, sztampowych przykïadów z dziedziny IT. Wyobraě sobie np. osobÚ, która chce wiedzieÊ, kiedy ceny akcji osiÈgnÈ okreĂlony poziom, lub kogoĂ, kto chce byÊ powiadamiany za kaĝdym razem, kiedy skïadane jest zamówienie przekraczajÈce okreĂlonÈ wartoĂÊ. Podobnie system inwentaryzacyjny musi wiedzieÊ, ĝe naleĝy zamówiÊ nowÈ partiÚ towaru, kiedy poziom zapasów spada poniĝej okreĂlonego progu, a rozwiÈzania z zakresu dashboardingu i monitorowania aktywnoĂci biznesowej (ang. business activity monitor — BAM) muszÈ mieÊ informacje o problemach, które majÈ raportowaÊ. Kup książkęPoleć książkę 158 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Rysunek 5.9. Niektóre z usáug, z którymi musiaáaby wspóápracowaü usáuga „OpóĨnienia”. Usáuga „OpóĨnienia” steruje kilkoma usáugami bezpoĞrednio (takimi jak „Rezerwacje” i „Plany lotów”), ale sama jest sterowana danymi pochodzącymi z pozostaáych usáug („Pogoda”, „Obraz operacyjny” i „Lotniska”) Chociaĝ architektura SOA wydaje siÚ byÊ zakorzeniona w interakcjach ¿Èda- nie/Odpowiedě, musisz równieĝ znaleěÊ sposób na obsïugÚ zdarzeñ biznesowych w ramach ograniczeñ i dogmatów SOA. Innymi sïowy: ? Jak moĪesz obsáuĪyü zdarzenia biznesowe w SOA? JednÈ z opcji jest trzymanie siÚ podstawowego podejĂcia SOA i przygotowanie usïugi, która generuje aktywnie zdarzenie i wysyïa komunikat do wszystkich zainte- resowanych usïug. ZwróÊ uwagÚ, ĝe dla takiego scenariusza usïuga ěródïowa musi mieÊ informacje o wszystkich zainteresowanych usïugach, co obejmuje rozumienie ich kontraktów. Jest to problematyczne, poniewaĝ wprowadza niepotrzebne powiÈ- zania pomiÚdzy ěródïem zdarzeñ a pozostaïymi usïugami. W poprzednim przy- kïadzie usïuga „Pogoda” powinna mieÊ informacje o usïugach „Opóěnienia” i „Obraz operacyjny”. Analogicznie, jeĂli usïuga „Lotniska” potrzebowaïaby informacji o pogodzie, aby aktualizowaÊ statusy lotnisk, musiaïbyĂ wprowadziÊ zmiany w usïu- dze „Pogoda”, ĝeby informowaïa równieĝ usïugÚ „Lotniska”. Musisz pamiÚtaÊ, ĝe w przeciwieñstwie do klasycznego scenariusza ¿Èdanie/Odpowiedě, nasza usïuga ěródïowa nie zajmuje siÚ usïugami docelowymi. InnÈ opcjÈ jest umoĝliwienie zainteresowanym usïugom sondowania pod kÈtem aktualizacji. Kaĝde zdarzenie zasadniczo posiada swój czas ĝycia, kiedy jest wciÈĝ dostÚpne w aktualnym stanie usïugi bÚdÈcej jego dostawcÈ. Zainteresowana usïuga moĝe sondowaÊ usïugÚ generujÈcÈ zdarzenia i dowiadywaÊ siÚ o interesujÈcych zdarzeniach. ZaletÈ tego podejĂcia w stosunku do poprzedniej opcji jest to, ĝe teraz kierunek zaleĝnoĂci jest wïaĂciwy. Usïugi przeprowadzajÈce sondowanie sÈ tymi, które sÈ zainteresowane informacjami. Problem z sondowaniem polega na tym, ĝe jeĂli jego interwaï jest zbyt dïugi, ominÈ CiÚ istotne zdarzenia. Z kolei jeĂli interwaï jest za krótki, wywoïasz niepotrzebne obciÈĝenie sieci. (Problem ten moĝna rozwiÈ- zaÊ — wrócÚ do tego w kontekĂcie wariacji na temat danego rozwiÈzania). Moĝesz zaïagodziÊ problem powiÈzañ usïug w opcji sondowania poprzez przesuniÚcie relacji na zewnÈtrz usïug. Jednym ze sposobów na to jest wzorzec Orkiestracja (omówiony w rozdziale 7.), który wykorzystuje zewnÚtrzny silnik prze- Kup książkęPoleć książkę 5.3. Wzorzec Odwrócenie Komunikacji 159 pïywu pracy. ½ródïo zdarzeñ moĝe wtedy posiadaÊ pojedynczÈ zaleĝnoĂÊ w punkcie koñcowym silnika przepïywu pracy. Silnik przepïywu pracy ma informacje o wszyst- kich zainteresowanych stronach i przekazuje im komunikaty. Jest to krok w dobrym kierunku, poniewaĝ usïugi nie sÈ powiÈzane i ïatwo jest wprowadzaÊ zmiany do przepïywu pracy, a takĝe dodawaÊ nowe usïugi. WadÈ jest stowarzyszenie logiki pomiÚdzy usïugami a przepïywem pracy. RozwaĝyliĂmy trzy róĝne rozwiÈzania, z których kaĝde ma swoje zalety, ale moĝe jesteĂmy w stanie zaproponowaÊ coĂ lepszego? MyĂlÚ, ĝe tak. ROZWIĄZANIE RozwiÈzanie do obsïugi zdarzeñ biznesowych caïy czas kryïo siÚ w tle. JeĂli chcesz dodawaÊ zdarzenia, to czemu by nie zaadaptowaÊ stylu architektonicznego zbudo- wanego wokóï zdarzeñ i nie wcieliÊ tego do SOA? Tak siÚ skïada, ĝe nie musimy ponownie wymyĂlaÊ koïa — istnieje juĝ odpowiedni styl architektoniczny, zwany architekturÈ sterowanÈ zdarzeniami (ang. event-driven architecture — EDA). Zdarzenie (ang. event) jest znaczÈcÈ zmianÈ majÈcÈ miejsce wewnÈtrz generatora zdarzeñ lub komponentu, który jest obserwowany przez generator zdarzeñ. Specy- fikacje zdarzeñ w EDA to zorganizowane encje podobne do kontraktów i komuni- katów SOA. Specyfikacja zdarzenia skïada siÚ z nagïówka i treĂci, gdzie nagïówek zawiera metadane, a treĂÊ zawiera faktycznÈ informacjÚ na temat zdarzenia. W prze- ciwieñstwie do tradycyjnych komunikatów, zdarzenia nie posiadajÈ okreĂlonego miejsca przeznaczenia. EDA jest zbliĝone do wzorca publikuj/subskrybuj (ang. publish/subscribe), ale posiada takĝe kilka róĝnic, takich jak perspektywa historyczna, która jest uzyskana poprzez traktowanie zdarzeñ jako strumieni, a nie wyizolowanych wystÈpieñ. Aby dostosowaÊ do SOA zdarzeniowy wzorzec wymiany komunikatów, moĝesz zrobiÊ, co nastÚpuje: 9 Zaimplementuj wzorzec Odwrócenie Komunikacji, uzupeániając SOA o architekturĊ EDA — moĪesz umoĪliwiü usáugom publikowanie strumienia zdarzeĔ, które w nich wystĊpują, zamiast bezpoĞrednio wywoáywaü usáugi. Przedstawiony na rysunku 5.10 wzorzec Odwrócenie Komunikacji zasadniczo zmie- nia kierunek przepïywu informacji. Zamiast wywoïywania usïug przez konsumen- tów usïug w celu uzyskania informacji, usïugi docierajÈ do konsumentów z aktu- alizacjami. Ta zamiana ról wymaga dwóch komponentów w obrÚbie usïugi lub raczej w komponencie brzegowym (poniewaĝ komponenty te nie sÈ zorientowane biznesowo). Pierwszym komponentem jest propagacja zdarzeñ. Zdarzenia powinny byÊ pakowane do formatu uzgodnionego dla inicjatywy SOA (lub zgodnie z kontraktem usïugi, jeĂli nie ma wspólnego kontraktu) i dystrybuowane (omawia to kolejny punkt, poĂwiÚcony mapowaniu technologii). Drugi komponent, procedura obsïugi zdarzeñ, umoĝliwia usïudze dziaïanie jako konsument usïug dla zdarzeñ wysïanych przez inne usïugi. Pierwszym zadaniem procedury obsïugi zdarzeñ jest filtrowanie przychodzÈcych zdarzeñ pod kÈtem Kup książkęPoleć książkę 160 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Rysunek 5.10. We wzorcu Odwrócenie Komunikacji komponent brzegowy usáugi poza „standardowymi” Īądaniami akceptuje i filtruje przychodzące zdarzenia. Kiedy usáuga ma gotową jakąĞ odpowiedĨ lub reakcjĊ na zdarzenie, komponent brzegowy równieĪ pakuje i ekspediuje ją do konsumentów usáug jako zdarzenie trafnoĂci. Jest to istotne, poniewaĝ wiele odebranych zdarzeñ moĝe nie byÊ istotne, szczególnie jeĂli infrastruktura pomiÚdzy usïugami nie jest wystarczajÈco inteligentna, by routowaÊ subskrypcje lub nimi zarzÈdzaÊ. DrugÈ rolÈ procedury obsïugi zdarzeñ jest routowanie odpowiednich zdarzeñ do komponentów usïugi, które mogÈ reago- waÊ na te zdarzenia — komponenty, które w modelu ¿Èdanie/Odpowiedě otrzy- maïyby nowe informacje w postaci ĝÈdañ. Jak pewnie zauwaĝyïeĂ, chociaĝ wzorzec Odwrócenie Komunikacji mówi o zda- rzeniach, to nie posiada w komponencie brzegowym komponentu zarzÈdzania sub- skrypcjami. Dzieje siÚ tak dlatego, ĝe zarzÈdzanie subskrypcjami wymaga zbyt wiele wysiïku niezwiÈzanego tak naprawdÚ z usïugami, takiego jak routowanie i sub- skrypcje trwaïe. AlternatywÈ do subskrypcji w usïugach jest przeniesienie odpo- wiedzialnoĂci na konsumenta lub infrastrukturÚ (lub oba te skïadniki). W tym celu moĝesz dostarczyÊ znane nazwy (adresy URI, kolejki itp.), pod którymi moĝna zna- leěÊ zdarzenia, a nastÚpnie skonfigurowaÊ zainteresowane usïugi do ich nasïuchiwania. Przyjrzyjmy siÚ usïudze „Opóěnienia” wspomnianej w opisie problemu. Na rysunku 5.11 widaÊ, ĝe teraz usïugi „Lotniska”, „Pogoda” i „Obraz operacyjny” przekazujÈ swoje zmiany usïudze „Opóěnienia”, a nie na odwrót. Ma to pozytywny wpïyw na ruch sieciowy, poniewaĝ usïuga „Opóěnienia” nie musi siÚ dïuĝej przej- mowaÊ tym, ĝe pominie jakÈĂ istotnÈ zmianÚ w trzech usïugach, które monitoruje. ZwróÊ teĝ uwagÚ, ĝe zastosowanie wzorca Odwrócenie Komunikacji nie oznacza, ĝe musisz przenosiÊ wszystkie swoje interakcje na zdarzenia. W tym przykïadzie usïuga „Opóěnienia” wciÈĝ posiada interakcje ¿Èdanie/Odpowiedě z usïugami „Plany lotów” i „Rezerwacje”. JeĂli usïuga „Opóěnienia” zidentyfikuje opóěnienie, moĝe spróbowaÊ zarezerwowaÊ miejsca w póěniejszych lotach dla osób, które nie zdÈĝyïy na przesiadkÚ. Kup książkęPoleć książkę 5.3. Wzorzec Odwrócenie Komunikacji 161 Rysunek 5.11. Relacje pomiĊdzy usáugami z rysunku 5.9 po zastosowaniu wzorca Odwrócenie Komunikacji. Teraz usáugi „Pogoda”, „Lotniska” i „Obraz operacyjny” przekazują swoje zmiany do usáugi „OpóĨnienia” Naleĝy zwróciÊ uwagÚ, ĝe przy ïÈczeniu wzorca Odwrócenie Komunikacji z wzor- cem ¿Èdanie/Reakcja lub ¿Èdanie/Odpowiedě poza odpowiadaniem konsumentowi usïugi (lub jako alternatywa tej czynnoĂci) usïuga powinna równieĝ zgïosiÊ zdarze- nie, informujÈc elementy nasïuchujÈce o efektach obsïugi ĝÈdania, tak aby subskry- bowane usïugi mogïy obsïuĝyÊ efekty zmian. We wzorcu Odwrócenie Komunikacji chodzi o implementacjÚ EDA na bazie SOA. Jak dotÈd przyglÈdaliĂmy siÚ prostej stronie tej kwestii, która obejmuje spo- radyczne lub wyizolowane zdarzenia. Ale bardzo silna koncepcja definiowana przez EDA to strumieñ zdarzeñ. Oznacza to, ĝe nie spoglÈdasz na zdarzenie w jego wïasnej postaci, ale raczej na ïañcuch powiÈzanych zdarzeñ w pewnym przedziale czasowym. Strumienie zdarzeñ mogÈ dostarczyÊ Ci zarówno trendy, jak i perspek- tywÚ historycznÈ. Dobrze wykorzystane mogÈ zapewniÊ Ci wywiad biznesowy i monitorowanie aktywnoĂci biznesowej w czasie rzeczywistym. Wzorzec Zagre- gowane Raportowanie, omówiony w rozdziale 7., pokazuje zastosowanie tych funk- cjonalnoĂci. Kolejnym wzorcem, który moĝesz poïÈczyÊ z Odwróceniem Komunikacji, jest wzorzec Potoki Równolegïe (omówiony w rozdziale 3.). Ta kombinacja moĝe byÊ zastosowana do dostarczenia implementacji SOA etapowej architektury sterowanej zdarzeniami (ang. staged event-driven architecture — SEDA). W skrócie, SEDA moĝe zapewniÊ moĝliwoĂÊ zwiÚkszenia wspóïbieĝnoĂci i przepustowoĂci rozwiÈza- nia w stosunkowo prosty sposób. WadÈ zastosowania wzorca Odwrócenie Komunikacji jest dodatkowa zïoĝonoĂÊ projektowania caïego systemu wykorzystujÈcego zdarzenia. Sposób radzenia sobie z tym problemem zostaï juĝ wspomniany — nie stosuj wyïÈcznie wzorca Odwró- cenie Komunikacji, a raczej poïÈcz go z innym wzorcem wymiany komunikatów wymienionym w tym rozdziale. JednÈ z rzeczy, na które naleĝy uwaĝaÊ i których naleĝy unikaÊ przy korzystaniu z wzorca Odwrócenie Komunikacji, jest bïÚdne koïo zdarzeñ. Ma to miejsce, kiedy jakieĂ zdarzenie uruchamia ïañcuch zdarzeñ, który wraca do ěródïa pierwotnego zdarzenia i powoduje ponowne uruchomienie tego samego lub podobnego zdarzenia. Kup książkęPoleć książkę 162 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Nie spotkaïem siÚ jeszcze z tym w praktyce, ale taka moĝliwoĂÊ istnieje. Sposobem radzenia sobie z tym problemem jest rejestrowanie i monitorowanie, np. za pomocÈ wzorca Straĝnik Usïugi omówionego w rozdziale 3. Przestawienie siÚ na wzorzec Odwrócenie Komunikacji komplikuje równieĝ procesy debugowania. Gdy coĂ pójdzie nie tak, musisz przeĂledziÊ problem wstecz, aĝ do motyla, którego skrzydïa zainicjowaïy reakcjÚ ïañcuchowÈ prowadzÈcÈ do tego problemu. Sposobem przeciwdziaïania jest scentralizowane rejestrowanie przez caïy proces rozwoju (i prawdopodobnie równieĝ w fazie produkcyjnej), co umoĝ- liwia odtworzenie systemu. Jest to bardziej skomplikowane niĝ podÈĝanie za bez- poĂrednim wywoïaniem stosu. Kolejnym wyzwaniem przejĂcia na wzorzec Odwrócenie Komunikacji jest doda- nie go, kiedy jesteĂ w trakcie budowania inicjatywy SOA i posiadasz juĝ wdroĝone usïugi wykorzystujÈce prostsze wzorce wymiany komunikatów. Nie potrafiÚ dostar- czyÊ ogólnych wskazówek dotyczÈcych remodelowania interakcji, poniewaĝ jest to ĂciĂle uzaleĝnione od sytuacji. JeĂli jednak chodzi o samÈ inicjatywÚ SOA, sekretem jest stopniowe przechodzenie. Inny zestaw wyzwañ zwiÈzanych z wzorcem Odwrócenie Komunikacji doty- czy szczegóïów implementacji. Wszakĝe wiele infrastruktur SOA (co najbardziej oczywiste, HTTP) nie obsïuguje zdarzeñ czy transmisji grupowych (multicastów). Zobaczmy, czy uda nam siÚ przezwyciÚĝyÊ te przeszkody. MAPOWANIE TECHNOLOGII Istnieje kilka opcji mapowania technologii dla implementacji wzorca Odwrócenie Komunikacji. PierwszÈ opcjÈ, która wydaje siÚ równieĝ najbardziej naturalna, jest zastoso- wanie korporacyjnej magistrali usïug (ESB). WiÚkszoĂÊ implementacji ESB moĝe zaadaptowaÊ wszystkie popularne wzorce wymiany komunikatów, w tym publi- kuj/subskrybuj. Listing 5.4 pokazuje, jak moĝna skonfigurowaÊ subskrypcjÚ w Apache ServiceMix (ESB na licencji open source). W tym celu dodaj sekcjÚ subskrypcji (sm:subscription) w sekcji konfiguracyjnej komponentu (sm:activationSpecs). Listing 5.4. Fragment kodu konfiguracyjnego doáączający subskrypcjĊ komponentu „picture” sm:activationSpecs sm:activationSpec componentName= sub service= foo:Subscriber ... sm:subscriptions sm:subscriptionSpec service= cop::picture / /sm:subscriptions /sm:activationSpec /sm:activationSpecs Kiedy chcesz zaimplementowaÊ wzorzec Odwrócenie Komunikacji z ESB, delegu- jesz odpowiedzialnoĂÊ za przekazywanie zdarzeñ i zarzÈdzanie subskrypcjami na infrastrukturÚ i wtedy moĝesz skoncentrowaÊ siÚ na planowaniu zdarzeñ oraz innych aktywnoĂciach biznesowych. Kup książkęPoleć książkę 5.3. Wzorzec Odwrócenie Komunikacji 163 Moĝesz uzyskaÊ jeszcze luěniejsze powiÈzania, stosujÈc infrastrukturÚ wymiany komunikatów (lub ESB), która obsïuguje tematy, choÊ nie jest to typowa infrastruk- tura usïug dla SOA. Tematy sÈ luěniej powiÈzane, poniewaĝ subskrybenci nie wie- dzÈ, kim jest wydawca — majÈ informacje jedynie o temacie, który ich interesuje. Problemem tego podejĂcia jest to, ĝe skoro subskrybenci nie wiedzÈ, kim jest wydawca, to infrastruktura musi zadbaÊ o to, ĝeby zdarzenia byïy publikowane tylko przez uwierzytelnione i zautoryzowane usïugi. Teraz zajmijmy siÚ bardziej problematycznymi infrastrukturami, takimi jak HTTP (usïugi RESTful) oraz proste TCP. Mamy tutaj dwie opcje. Pierwsza opcja to napisaÊ niezbÚdnÈ infrastrukturÚ jako element komponentu brzegowego kaĝdej usïugi. Innymi sïowy, naleĝy przygotowaÊ wïasnÈ logikÚ utrzy- mywania subskrypcji i aktywnego wysyïania kaĝdego wygenerowanego zdarzenia do wszystkich zainteresowanych subskrybentów. Chociaĝ jest to technicznie wyko- nalne, nie zalecam podÈĝania tÈ drogÈ, chyba ĝe jesteĂ dostawcÈ platform poĂred- niczÈcych. Lepiej skupiÊ siÚ na podstawowej dziaïalnoĂci i wartoĂci biznesowej swo- ich rozwiÈzañ i nie próbowaÊ tworzyÊ delikatnego elementu infrastruktury, co i tak prawdopodobnie nie wyjdzie za pierwszym razem. Druga opcja, wedïug mnie bardziej interesujÈca, zwiÈzana jest z aplikacjami typu push (tak wïaĂciwie to pull), których prawdopodobnie uĝywasz na co dzieñ — blogi i ich czytelnicy. Kiedy publikujÚ na blogu nowe zdarzenie (post), nie jest ono natychmiastowo wysyïane do subskrybentów blogu. WïaĂciwie nigdy nie jest aktyw- nie wysyïane. Zamiast tego nowe zdarzenie jest dodawane do strumienia zdarzeñ (kanaï RSS lub Atom), który zawiera najnowsze wydarzenia. Subskrybenci, którzy zarzÈdzajÈ subskrypcjÈ po swojej stronie niezaleĝnie ode mnie (luěne powiÈzania), decydujÈ, jak czÚsto muszÈ sondowaÊ mój strumieñ zdarzeñ, ĝeby nie przegapiÊ istotnych zdarzeñ. Ta decyzja jest oparta na liczbie zdarzeñ utrzymywanych w stru- mieniu, czÚstotliwoĂci nowych zdarzeñ oraz opóěnieniu, na jakie subskrybenci mogÈ sobie pozwoliÊ przy obsïudze zdarzeñ. ZwróÊ uwagÚ, ĝe konsumenci, którzy potrze- bujÈ maïego opóěnienia pomiÚdzy wystÈpieniem zdarzenia a powiadomieniem, bÚdÈ prawdopodobnie potrzebowaÊ powiadamiania online i nie bÚdÈ mogli skorzystaÊ z tej metody. Jak pewnie zauwaĝyïeĂ podczas omawiania wzorca ¿Èdanie/Odpowiedě (pod- rozdziaï 5.1), protokóï APP (ang. Atom Publishing Protocol) jest popularnym wybo- rem dla formalizowania kolekcji w usïugach sieciowych typu RESTful, podobnie jak wersje formatu JSON, takie jak OData i GData. Jak wczeĂniej wspomniano, element architektury EDA we wzorcu Odwrócenie Komunikacji pozwala traktowaÊ zdarzenia jako strumieñ, a nie jako wyizolowane instancje. Strumienie zdarzeñ mogÈ poprawiÊ Twoje rozwiÈzania jeszcze bardziej, jeĂli zastosujesz dodatkowÈ koncepcjÚ architektonicznÈ zwanÈ zïoĝonym przetwa- rzaniem zdarzeñ (ang. complex event processing — CEP). Jak wskazuje nazwa, CEP polega na badaniu strumieni zdarzeñ pod kÈtem zïoĝonych wzorców. Prawdopo- dobnie najïatwiej bÚdzie wyjaĂniÊ to na przykïadzie. Kup książkęPoleć książkę 164 ROZDZIAà 5. Wzorce dotyczÈce wymiany komunikatów Czas Īycia zdarzenia Bez wzglĊdu na to, czy do publikowania zdarzeĔ wykorzystujesz kanaáy (ang. feeds), czy teĪ stosujesz podejĞcie oparte na kolejkach, musisz wziąü pod uwagĊ czas Īycia (ang. time to live — TTL) zdarzeĔ. Poprzez TTL rozumiem przedziaá czasu, w którym zdarzenie powinno byü dostĊpne dla konsumentów, zanim stanie siĊ nieistotne. JeĞli wykorzystujesz zdarzenia w jĊzyku programowania, parametr TTL jest nieodáączny („wszystkiemu trzeba poĞwiĊciü naleĪytą uwagĊ, jeĞli chce siĊ uniknąü poraĪki”). JeĞli konsument jest nieobecny, kiedy zdarzenie jest przywoáywane, to jego problem. W SOA rozsądniej jest pozwoliü na tymczasowe oddzielenie pomiĊdzy czasem wywoáania zdarzenia a czasem jego skonsumowania. Takie tymczasowe oddzielenie umoĪliwia zwiĊkszenie autonomii i zapewnia luĨne powiązania zarówno dla generatora zdarzeĔ, jak i konsumenta zdarzeĔ. Druga strona medalu jest taka, Īe teraz musisz uwzglĊd- niaü czas Īycia zdarzeĔ, aby uniknąü przetwarzania przestarzaáych informacji, zbyt duĪego opóĨnienia oraz problemów z wydajnoĞcią. TTL zmienia siĊ w zaleĪnoĞci od znaczenia biznesowego zdarzenia, nie ma wiĊc Īad- nych sztywnych reguá. Dwie ogólne zasady to takie, Īe TTL dla zdarzeĔ cyklicznych (np. aktualizacje cen akcji) jest zazwyczaj czĊstotliwoĞcią cyklu, a TTL dla zdarzeĔ jednorazowych (np. nowe zamówienie) jest z reguáy znacznie dáuĪsze. Listing 5.5 pokazuje przykïadowe zapytanie we wbudowanym silniku CEP, które napisaïem kilka lat temu (oparte na technologii C# LINQ). Zapytanie to analizuje strumieñ zdarzeñ logowania i uruchamia alarm za kaĝdym razem, kiedy wystÈpiÈ trzy nieudane logowania pod rzÈd u tego samego uĝytkownika. Listing 5.5. Ustawiczne zapytanie dotyczące wywoáania okreĞlonego zdarzenia w przypadku trzech kolejnych nieudanych logowaĔ var loginRecords = engine.GetEventSource Login (); engine.AddQuery(() = from names in loginRecords.Stream group names by names.Name into logins from login in logins let next = logins.FirstOrDefault( t = t.LoginTime login.LoginTime) let nextNext = null == next ? null ´: logins.FirstOrDefault(t = t.LoginTime next.LoginTime) where !login.Successful (null != next !next.Successful) ´(null != nextNext !nextNext.Successful) select login, HandleAlert); Istnieje wiele komercyjnych silników CEP firm takich jak SAP, TIBCO czy IBM.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Wzorce SOA
Autor:
Sklep
Format
Cena
Helion.pl Helion.pl
książka
41,17 zł
Idź do sklepu »

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ą: