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)