Tytuł oryginału: SOA Patterns - Alt Control Delete › download › wzosoa.pdf · Rozdzia 1. Rozwizywanie problemów SOA za pomoc wzorców 25 1.1. Definicja architektury oprogramowania

Tytuł oryginału: SOA Patterns

Tłumaczenie: Lech LachowskiProjekt 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 kompletnei 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 HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: 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/wzosoaMoż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ść

http://helion.pl/page54916~rt/wzosoa

http://helion.pl/page54916~rf/wzosoa

http://helion.pl/page54916~ro/wzosoa

http://helion.pl/page54916~/

http://ebookpoint.pl/r/4CAKF

Spis tre�ciPrzedmowa 11Wst�p 13O ksi��ce 15O autorze 19O ilustracji na ok�adce 21

CZ�� I WZORCE SOA ...................................................................................... 23

Rozdzia� 1. Rozwi�zywanie problemów SOA za pomoc� wzorców 251.1. Definicja architektury oprogramowania 261.2. Architektura zorientowana na us�ugi 27

1.2.1. Czym jest, a czym nie jest SOA 281.2.2. Korzy�ci architektoniczne p�yn�ce ze stosowania SOA 311.2.3. SOA dla przedsi�biorstw 34

1.3. Pokonywanie wyzwa� SOA za pomoc� wzorców 351.3.1. Struktura wzorca 351.3.2. Od wyizolowanego wzorca do j�zyka wzorców 38

1.4. Podsumowanie 401.5. Dalsza lektura 40

Rozdzia� 2. Podstawowe wzorce strukturalne 412.1. Wzorzec Host Us�ugi 422.2. Wzorzec Us�uga Aktywna 482.3. Wzorzec Us�uga Transakcyjna 532.4. Wzorzec Przep�yw Pracy 592.5. Wzorzec Komponent Brzegowy 642.6. Podsumowanie 692.7. Dalsza lektura 69

Rozdzia� 3. Wzorce dotycz�ce wydajno�ci, skalowalno�ci i dost�pno�ci 713.1. Wzorzec Oddzielone Wywo�anie 733.2. Wzorzec Potoki Równoleg�e 793.3. Wzorzec Us�uga Przetwarzania Sieciowego 843.4. Wzorzec Instancja Us�ugi 893.5. Wzorzec Wirtualny Punkt Ko�cowy 933.6. Wzorzec Stra�nik Us�ugi 963.7. Podsumowanie 1013.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 1034.1. Wzorzec Bezpieczne Komunikaty 1064.2. Wzorzec Bezpieczna Infrastruktura 1114.3. Wzorzec Firewall Us�ugi 1184.4. Wzorzec Dostawca To�samo�ci 1234.5. Wzorzec Monitor Us�ugi 1314.6. Podsumowanie 1384.7. Dalsza lektura 139

Rozdzia� 5. Wzorce dotycz�ce wymiany komunikatów 1415.1. Wzorzec ��danie/Odpowied� 1435.2. Wzorzec ��danie/Reakcja 1495.3. Wzorzec Odwrócenie Komunikacji 1565.4. Wzorzec Saga 1655.5. Podsumowanie 1745.6. Dalsza lektura 175

Rozdzia� 6. Wzorce dotycz�ce konsumentów us�ug 1776.1. Wzorzec Rezerwacja 1786.2. Wzorzec Fasada Kompozytowa (Portal) 1876.3. Wzorzec Klient/Serwer/Us�uga 1936.4. Podsumowanie 2006.5. Dalsza lektura 200

Rozdzia� 7. Wzorce dotycz�ce integracji us�ug 2037.1. Wzorzec Magistrala Us�ug 2047.2. Wzorzec Orkiestracja 2137.3. Wzorzec Zagregowane Raportowanie 2217.4. Podsumowanie 2317.5. Dalsza lektura 231

CZ� II SOA W PRAWDZIWYM WIECIE ......................................................... 233

Rozdzia� 8. Antywzorce us�ug 2358.1. Antywzorzec Supe� 2368.2. Antywzorzec Nanous�uga 2428.3. Antywzorzec Integracja Transakcyjna 2498.4. Antywzorzec Stare Nawyki 2548.5. Podsumowanie 2578.6. Dalsza lektura 258




Spis tre�ci 9

Rozdzia� 9. Podsumowanie — studium przypadku 2599.1. Problem 2609.2. Rozwi�zanie 2619.3. Podsumowanie 280

Rozdzia� 10. SOA a rzeczywisto�� 28310.1. REST a SOA 284

10.1.1. Co to w�a�ciwie jest REST? 28410.1.2. Czym ró�ni� si� REST i SOA 28610.1.3. RESTful SOA 287

10.2. SOA i chmura 28810.2.1. Zupa technologiczna chmury 28910.2.2. Chmura i fa�szywe przes�anki przetwarzania rozproszonego 29010.2.3. Chmura i SOA 292

10.3. SOA i big data 29310.3.1. Mix technologiczny big data 29410.3.2. Jak dzia�a SOA z big data 296

10.4. Podsumowanie 29810.5. Dalsza lektura 299

Dodatek Od atrybutów jako�ciowych do wzorców 301

Skorowidz 311




10 Spis tre�ci




Wzorce dotycz�cewymiany komunikatów

W tym rozdziale� Interakcje pomi�dzy us�ugami i konsumentami

� Komunikaty skorelowane

� Czas �ycia zdarze

W rozdzia�ach 2. i 3. przyjrzeli�my si� wzorcom takim jak Komponent Brzegowyi 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 pierwszymz trzech kolejnych rozdzia�ów omawiaj�cych ró�ne aspekty interakcji us�ug. W ko�cuto 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�ugz ich „klientami” — konsumentami us�ug. Konsument us�ug to dowolny komponentlub fragment kodu, który wspó�dzia�a z us�ug�. Wzorce omówione w tym rozdzialedotycz� 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 procesyi zachowania poprzez kontrakty, które sk�adaj� si� z komunikatów w wykrywalnychadresach”. To znacznie upraszcza interakcje us�ug — po prostu wysy�asz komunikati otrzymujesz komunikat zwrotny, prawda? Dlaczego wi�c musimy po�wi�ci� inte-rakcjom us�ug ca�y rozdzia�, a nawet dwa?




142 ROZDZIA� 5. Wzorce dotycz�ce wymiany komunikatów

Rysunek 5.1. Rozdzia� ten koncentruje si� na ��czeniu us�ug z interfejsamiu�ytkowników. To pierwszy z rozdzia�ów tej ksi��ki powi�conykonsumentom us�ug

To prawda, �e komunikaty s� podstawowym budulcem interakcji us�ug, aleistnieje wiele sposobów interakcji wykorzystuj�cych ten budulec. Ludzie podobnieu�ywaj� zda� jako budulca dla komunikacji i interakcji. Kiedy kontaktujesz si�z przedstawicielem handlowym, mo�liwych jest kilka interakcji:

� Mo�esz zada� okre�lone pytanie i uzyska� odpowied (wzorzec��danie/Odpowied z podrozdzia�u 5.1).

� 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).

� Przedstawiciel handlowy mo�e zadzwoni� do Ciebie i poinformowa� Ci�o nowych produktach (wzorzec Odwrócenie Komunikacji z podrozdzia�u 5.3).

� 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ówjako�ciowych tej architektury. Zobaczymy, co sprawia, �e wzorzec interakcji, takijak komunikacja asynchroniczna, dzia�a zgodnie z zasadami SOA i zachowuje korzy-�ci SOA.

W tym rozdziale zajmiemy si� nast�puj�cymi wzorcami:

� ��danie/Odpowied� (ang. Request/Reply) — Umo�liwia konsumentowius�ug prost� interakcj� z us�ug�.

� ��danie/Reakcja (ang. Request/Reaction) — Tymczasowo oddziela ��danieod konsumenta us�ug oraz odpowied od us�ugi.




5.1. Wzorzec ��danie/Odpowied 143

� Odwrócenie Komunikacji (ang. Inversion of Communications) — Obs�ugujezdarzenia biznesowe w SOA.

� Saga (ang. Saga) — Umo�liwia osi�gni�cie konsensusu rozproszonegopomi�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 opiswzorca ��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. Powodemdo omówienia danego wzorca w tej ksi��ce jest jednak to, �e nadal istnieje kilkakwestii, na które warto zwróci� uwag�, korzystaj�c z niego w SOA. Wspomn� o nichw kontek�cie omawiania rozwi�zania. Najpierw przyjrzyjmy si� problemowi.

PROBLEM

Podczas opracowywania jednowarstwowego oprogramowania, które dzia�a wewn�trzjednego procesu i pojedynczej przestrzeni pami�ci, stosunkowo �atwo jest uzyska�interakcj� komponentów. Kiedy komponent ��daj�cy potrzebuje czego� od innegokomponentu (podmiotu odpowiadaj�cego), mo�e �atwo uzyska� referencj� do tegokomponentu, np. poprzez jego instancjonowanie. Podmiot ��daj�cy mo�e wtedywywo�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, drugikomponent 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� wykorzystanaw SOA — ró�nic� stanowi sposób ich wykorzystania. Wrócimy do tegow dalszej cz��ci rozdzia�u.

Pierwsz� rzecz�, jak� musimy zrobi�, jest znalezienie sposobu na interakcj� us�ugz 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),

?





Rysunek 5.2. Obiekty zinstancjonowane w obr�bie jednegoprocesu w porównaniu z us�ugami. W przypadku obiektulokalnego wys�anie ��dania z jednego komponentu do drugiegojest proste — otrzymujesz referencj� do tego drugiegokomponentu i wykonujesz ��danie, wywo�uj�c go. W SOA��daj�cy i konsument nie znajduj� si� w jednej przestrzeniadresowej. 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 bardziejskomplikowane

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ównow zakresie implementacji, jak i wsparcia.

ROZWI�ZANIE

Wyrafinowanie bywa uzasadnione, ale czasem potrzebna jest prosta synchronicznainterakcja pomi�dzy dwoma zdalnymi komponentami.

Wylij ��danie od konsumenta, obs�u� ��danie synchronicznie i wylij z us�ugikomunikat z odpowiedzi�. Zarówno ��danie, jak i odpowied nale�� do us�ugiodbieraj�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, przetwarzaje synchronicznie i zwraca odpowied lub wynik. Jedn� rzecz�, na któr� nale�yzwró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��demu 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

�





Rysunek 5.3. Wzorzec��danie/Odpowied definiujekomunikaty ��da� i odpowiedziw kontrakcie us�ugi. Kiedyus�uga otrzymuje ��daniew odpowiednim formacie,przetwarza je synchroniczniei zwraca konsumentowi us�ugkomunikat 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 zamiarlub zadanie, które us�uga ma wykona�, a tak�e dane wej�ciowe niezb�dne do jegowykonania. 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, czylirozproszone modele obiektowe. Powiniene� by� ostro�ny przy modelowaniu kon-traktów us�ug z nastawieniem na RPC — mo�e mie� to niekorzystny wp�yw naTwoje 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 napolecenia i nastawionymi na wysy�anie tylko parametrów niezb�dnych do wykonaniadzia�ania. Maj� one pewne stanowe oczekiwania ze strony us�ugi oraz domniemaneoczekiwania odno�nie tego, co ma sta� si� po stronie konsumenta. Dokumentowo-centryczne komunikaty nie robi� takich za�o�e�. Posiadanie kompletnej jednostkipracy 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ócenieKomunikacji w podrozdziale 5.3.

W tabeli 5.1 przedstawiono trzy sposoby na to, aby dokumentowo-centrycznekomunikaty mog�y zawiera� wi�cej kontekstu.





Tabela 5.1. Opcje dostarczenia kontekstu w komunikacie dokumentowo-centrycznym

Kontekst Wyjanienie

Historia Komunikaty mog� zawiera� interakcje do okre�lonego momentu, podobniejak okruszki chleba w bajce o Jasiu i Ma�gosi. Je�li w scenariuszu zamawianiapierwszym krokiem by�o pobranie danych konsumenta, a bie��cymkrokiem jest z�o�enie zamówienia (ka�da czynno�� wykonywana przezinn� us�ug�), to komunikat przesy�any do us�ugi zamawiania zawiera�byinformacje o konsumencie

Przysz�o�� Komunikat mo�e zawiera� opcje, z których konsument mo�e skorzysta�w celu wype�nienia interakcji. Je�li w scenariuszu zamawiania poprzednimkrokiem by�o zarezerwowanie zamówienia (patrz wzorzec Rezerwacjaw rozdziale 6.), komunikat zwrotny móg�by zawiera� informacje wymaganedo potwierdzenia rezerwacji

Kompletna przysz�o�� Innym sposobem zapewnienia kontekstu jest, aby format komunikatuzawiera� kompletne dane szczegó�owe niezb�dne do przeprowadzeniainterakcji. W przyk�adzie zamawiania oznacza�oby to, �e komunikatposiada�by szkielet do obs�ugi szczegó�ów zamówienia i kwestii z nimzwi�zanych, a zaanga�owane strony wype�nia�yby puste pola wrazz post�powaniem interakcji

Nale�y zwróci� uwag� na dwie kwestie. Komunikaty mog� ��czy� kilka typówkontekstu, 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�daz przychodz�cych mi do g�owy technologii umo�liwia implementacj� tego wzorcaw 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 fragmentkodu z kreatora nowego projektu dla biblioteki us�ug WFC w Visual Studio 2010Microsoftu. Przyk�adowy kod pokazuje, jak wzi�� prost� klas� i udost�pni� jejmetody 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); }

public class service1 : IService1 { public string MyOperation1(string myValue) {

Udost�pnia metod� jako us�ug� sieciow�





return "Hello: " + myValue; } public string MyOperation2(DataContract1 dataContractValue) { return "Hello: " + dataContractValue.FirstName; } }

[DataContract] public class DataContract1 { string firstName; string lastName;

[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 implementacjainterakcji RPC.

Sytuacja jest nieco lepsza w przypadku drugiej metody (MyOperation2). Tutajprosty 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 ramachodpowiedzi.

Takie podej�cie nie jest unikatowe dla platformy .NET — kolejnym przyk�ademmo�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� fragmentowikodu 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/[email protected]/�private-0c1e3facdd1a4252aad07effeb7d68cc9/full</id> <updated>2007-06-29T19:22:12.000Z</updated>

Akceptujedokument(kontraktdanych) jakoparametr

Obs�ugujedokumentna sposóbRPC(nie zwracadokumentu)

Definiuje podstawowydokument (brakuj�ce ��czado powi�zanych danych)





<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/[email protected]/ �private-0c1e3facdd1a4252aad07effeb7d68cc9/full'></link> <link rel='self' type='application/atom+xml' href='http://www.google.com/calendar/feeds/[email protected]/ �private-0c1e3facdd1a4252aad07effeb7d68cc9/full'></link> <author> <name>John Doe</name> <email>[email protected]</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/[email protected]/ �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/[email protected]/ �private-0c1e3facdd1a4252aad07effeb7d68cc9/full/ �aaBxcnNqbW9tcTJnaTT5cnMybmEwaW04bXMgbWFyY2guam9AZ21haWwuY29t'></link> <author> <name>John Doe</name> <email>[email protected]</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/[email protected]/ �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>




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�cicielaitd.) otrzymujesz wszystkie zestawienia ze wszystkimi szczegó�ami, a tak�e wskanikdo pobrania ka�dego wpisu kalendarza bezpo�rednio. Wynik wykorzystuje protokó�Google GData, który z kolei jest oparty na protokole APP (ang. Atom PublishingProtocol). Zwró� uwag�, �e kontrakt dla akceptowania tego dokumentu XML jestró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óremog� zmienia� si� z czasem.

Podsumowuj�c, wzorzec ��danie/Odpowied jest obs�ugiwany przez wszystkietechnologie umo�liwiaj�ce zdaln� komunikacj�. Wybór pomi�dzy RPC a podej�ciemdokumentowo-centrycznym jest decyzj� projektow�, która nie jest determinowanaprzez technologi�. Musi ona zosta� podj�ta przez programistów lub architektówdanego rozwi�zania.

ATRYBUTY JAKO CIOWEWzorzec ��danie/Odpowied jest prostym wzorcem ��cz�cym konsumenta us�ugz us�ug�, z któr� chce on wej�� w interakcj�. B�d�c wzorcem podstawowym, nierozwi�zuje wi�kszo�ci kwestii zwi�zanych z atrybutami jako�ciowymi, z wyj�tkiemzapewnienia 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 jakociowe wzorca ��danie/Odpowied i przyk�adowe scenariusze

Atrybut jakociowy Konkretny atrybut Przyk�adowy scenariusz

Czas opracowywania atwy rozwój Podczas fazy rozwoju udost�pnianie nowychfunkcjonalno�ci (przygotowanych uprzednio)w us�udze nie powinno zaj�� wi�cej ni� pó� dnia,wliczaj�c implementacj� i testy

Testowalno�� Pokrycie Podczas fazy rozwoju ka�da funkcjonalno��us�ugi powinna mie� 100-procentowe pokrycietestowe

Jak wspomniano wcze�niej, ��danie/Odpowied jest podstawowym synchronicz-nym wzorcem komunikacyjnym. Nast�pny wzorzec interakcji koncentruje si� naimplementacji 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 musioczekiwa�, a� us�uga zako�czy przetwarzanie jego ��dania, zanim b�dzie móg�





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 lepiejwyja�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 natemat danej osoby (wpisuje numer seryjny paszportu itd.), a nast�pnie przegl�dapaszport i porównuje zdj�cie. W ci�gu kilku ostatnich lat pa�stwa na ca�ym �wieciezacz��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�ywudla wydawania e-paszportów.

Rysunek 5.4. Proces rejestracji. Kiedy interfejs u�ytkownika (UI) wysy�a do us�ugie-paszportu zapytanie o wydanie paszportu, us�uga, aby spe�ni� to ��danie,musi wspó�pracowa� z kilkoma innymi us�ugami





Jak wida�, jednym z etapów schematu przep�ywu jest rejestrowanie osoby w baziedanych biometrii (która jest elementem us�ugi biometrycznej). Chocia� nie wynikato z samego schematu interakcji, zadanie rejestracji mo�e zaj�� sporo czasu, ponie-wa� us�uga biometryczna wewn�trznie sprawdza, czy istniej� duplikaty. Jest toniezb�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�estanowi� 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 ��daniema 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 sytuacjezdarzaj� si� równie� w innych systemach. Przyk�adowo, przy zakupie udzia�óww funduszu powierniczym transakcja nie jest przeprowadzana natychmiastowo,ale prawdopodobnie b�dziesz chcia� wiedzie�, kiedy zostanie zako�czona. Innymprzyk�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�ugoraz 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�ytkownikapozostaje w stanie reagowania. Platforma .NET posiada komponent zwany Backgro-undWorker, który dokonuje tej separacji i pozwala interfejsowi u�ytkownika nadysponowanie 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�dziedost�pna, gdy konsument odzyska sprawno��. Ponadto w�tek wykorzystuje zasobykonsumenta — co si� stanie, je�li przetwarzanie ��dania b�dzie trwa�o kilka godzinlub dni? Dochodzi jeszcze kwestia odpowiedzialno�ci. To us�uga ma do wykonaniazadanie, 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 zamawiasztowar online, nie siedzisz, czekaj�c, a� system wy�le Ci ten towar. W zamian systempowiadamia 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 najaki� czas nie sprawdzisz statusu zamówienia. Podobnie jak w poprzednim podej�ciuna Tobie jako na konsumencie us�ug spoczywa w tym przypadku odpowiedzialno��za rekompensowanie niedoci�gni�� us�ugi.

?





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 wzorcaSaga 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 klientaz powodu jej z�ych skutków. Tak naprawd� potrzebujesz jako� zaimplementowa�komunikacj� asynchroniczn� w SOA w mo�liwie jak najprostszy sposób. Oto comusisz zrobi�:

Zastosuj wzorzec ��danie/Reakcja i zaimplementuj komunikacj�asynchroniczn� pomi�dzy konsumentami us�ug a us�ug�. Zaimplementujwymian� 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�. Pierwszainterakcja 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�ugamusi zainicjowa� interakcj� z konsumentem us�ug i wys�a� mu odpowied lub reakcj�.

Rysunek 5.5. Wzorzec��danie/Odpowieddefiniuje komunikaty��dania i odpowiedziw kontrakcie us�ugi. Kiedyus�uga otrzymuje ��danie,przetwarza je i przygotowujereakcj�. Kiedy reakcja jestgotowa, 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� wymianykomunikató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�ugibiometrycznej. Teraz kiedy us�uga biometryczna otrzymuje komunikat rejestracji,reaguje komunikatem „rejestrowanie” informuj�cym klienta, �e ��danie zosta�oodebrane. Po zako�czeniu procesu rejestrowania, z powodzeniem lub z b��dem,przygotowywana jest odpowied z rekordami rejestracji, która wysy�ana jest doklienta.

�





UWAGA W scenariuszu przedstawionym na rysunku 5.6 sensowne by�obyzastosowanie wzorca Saga (omówionego w podrozdziale 5.4) do wycofywaniapozosta�ych us�ug, je�li sprawdzanie przez us�ug� biometryczn� zako�czy�obysi� 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 zwracastatus

Wzorzec ��danie/Reakcja jest wykorzystany we wzorcu Oddzielone Wywo�anie(omówionym w rozdziale 2.). Ró�nica pomi�dzy tymi dwoma wzorcami polega natym, �e ��danie/Reakcja oddziela odpowied od ��dania, podczas gdy OddzieloneWywo�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�narozwa�y� zastosowanie bardziej zaawansowanych wzorców, takich jak wzorzec Sagaopisany w podrozdziale 5.4.





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 komponentubrzegowego).

Przyjrzyjmy si� niektórym szczegó�om implementacji, o które nale�y zadba�.


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�dzieszpotrzebowa� 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 konsumentus�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 kodpo stronie klienta wymagany do wysy�ania komunikatów asynchronicznych.

Z punktu widzenia architektonicznego reakcja jest komunikatem wysy�anymprzez us�ug�. Jednak z punktu widzenia implementacji mo�e ona by� równie�zaimplementowana w formie pobierania jej przez konsumenta us�ug.

Komunikaty skorelowaneJedno 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 jestsposób identyfikacji, �e te dwa komunikaty s� powi�zane.

Mechanizm rozwi�zuj�cy ten problem znany jest jako identyfikator korelacji i jakwskazuje 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-Addressingposiada np. relacj� nag�ówka identyfikatora komunikatu, która mo�e by� u�yta dlaokre�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 korelacjiwraz z zawarto�ci� tych zestawów.

Listing 5.3. Wykorzystuj�cy wzorzec ��danie/Reakcja kod klienta s�u��cy dowysy�ania komunikatów

boolean useTwoChannels = true;

...





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 niejest zbyt skomplikowana. Na rysunku 5.7 przedstawiono kolejne etapy. Kiedy kon-sument us�ug wysy�a ��danie, otrzymuje w ramach odpowiedzi adres reakcji (w tymprzypadku URI). Konsument otrzymuje równie� token czasu okre�laj�cy, kiedymo�na si� spodziewa� odpowiedzi. Po up�ywie wskazanego czasu konsument wysy�adrugie ��danie do us�ugi, tym razem prosz�c o odpowied (np. za pomoc� pole-cenia GET).

Rysunek 5.7. Implementacjawzorca ��danie/Reakcja na baziewzorca ��danie/Odpowied.Komunikat zwrotny ��daniaobjania, gdzie b�dzie mo�naznale� reakcj� i jaki jestszacowany czas dostarczenia(ang. Estimated Time of Arrival— ETA). Po up�ywie czasu ETA,jeli konsument us�ug nie jestzaj�ty, mo�e przej� do adresureakcji w us�udze i samodzielniepobra� reakcj�

UWAGA Do �ledzenia czasu mo�esz u konsumenta zastosowa� wzorzec Us�ugaAktywna omówiony w rozdziale 2.





T� drog� (technologi� push zamiast pull) nale�y wybra�, kiedy nie jeste� w staniestworzy� 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 jegozastosowaniem. 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óryprzytrzymuje 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 jakociowe wzorca ��danie/Reakcja i przyk�adowe scenariusze


Elastyczno�� Tymczasowe powi�zania W normalnych warunkach system powinienpowiadamia� stron� zamawiaj�c� o wysy�cezamówienia w ci�gu dwóch godzin od nadaniapaczki

Wydajno�� Reagowanie W normalnych warunkach interfejsu�ytkownika nie b�dzie zawieszony podczaswykonywania d�ugotrwa�ych operacji (takichjak wyszukiwania i przeliczanie kursu)

Wzorzec ��danie/Odpowied demonstruje synchroniczn� komunikacj� pomi�-dzy konsumentami us�ug a us�ugami. Z kolei wzorzec ��danie/Reakcja demonstrujekomunikacj� asynchroniczn�. Nale�y sprawdzi�, kiedy mo�liwa jest komunikacjawykorzystuj�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�dnedo 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 musipoprosi� us�ug� o nowe informacje? Czy us�uga sama go powiadomi? Czy us�ugab�dzie chcia�a ponie�� koszty powi�za�?




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 proaktywniezajmowa� 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 dlatych 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óreb�d� zewn�trzne (np. us�ugi dostarczaj�ce raporty pogodowe i informacje o stanachlotnisk). 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ówdostarczane 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, �eprzyk�ad linii lotniczych jest ca�kiem popularny, ale jest te� wiele innychbardziej praktycznych, sztampowych przyk�adów z dziedziny IT. Wyobrasobie np. osob�, która chce wiedzie�, kiedy ceny akcji osi�gn� okre�lonypoziom, lub kogo�, kto chce by� powiadamiany za ka�dym razem, kiedysk�adane jest zamówienie przekraczaj�ce okre�lon� warto��. Podobnie systeminwentaryzacyjny musi wiedzie�, �e nale�y zamówi� now� parti� towaru,kiedy poziom zapasów spada poni�ej okre�lonego progu, a rozwi�zania z zakresudashboardingu i monitorowania aktywno�ci biznesowej (ang. business activitymonitor — BAM) musz� mie� informacje o problemach, które maj� raportowa�.





Rysunek 5.9. Niektóre z us�ug, z którymimusia�aby wspó�pracowa� us�uga„Opónienia”. Us�uga „Opónienia” sterujekilkoma us�ugami bezporednio (takimijak „Rezerwacje” i „Plany lotów”), ale samajest sterowana danymi pochodz�cymiz pozosta�ych us�ug („Pogoda”, „Obrazoperacyjny” i „Lotniska”)

Chocia� architektura SOA wydaje si� by� zakorzeniona w interakcjach ��da-nie/Odpowied, musisz równie� znale� sposób na obs�ug� zdarze� biznesowychw 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 przygotowanieus�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 musimie� informacje o wszystkich zainteresowanych us�ugach, co obejmuje rozumienieich 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 „Obrazoperacyjny”. Analogicznie, je�li us�uga „Lotniska” potrzebowa�aby informacjio 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�, �ew przeciwie�stwie do klasycznego scenariusza ��danie/Odpowied, nasza us�ugaród�owa nie zajmuje si� us�ugami docelowymi.

Inn� opcj� jest umo�liwienie zainteresowanym us�ugom sondowania pod k�temaktualizacji. 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�ugamo�e sondowa� us�ug� generuj�c� zdarzenia i dowiadywa� si� o interesuj�cychzdarzeniach. Zalet� tego podej�cia w stosunku do poprzedniej opcji jest to, �e terazkierunek 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, �eje�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 poprzezprzesuni�cie relacji na zewn�trz us�ug. Jednym ze sposobów na to jest wzorzecOrkiestracja (omówiony w rozdziale 7.), który wykorzystuje zewn�trzny silnik prze-

?





p�ywu pracy. �ród�o zdarze� mo�e wtedy posiada� pojedyncz� zale�no�� w punkcieko�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 jestwprowadza� zmiany do przep�ywu pracy, a tak�e dodawa� nowe us�ugi. Wad� jeststowarzyszenie 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�ejeste�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 chceszdodawa� zdarzenia, to czemu by nie zaadaptowa� stylu architektonicznego zbudo-wanego wokó� zdarze� i nie wcieli� tego do SOA? Tak si� sk�ada, �e nie musimyponownie wymy�la� ko�a — istnieje ju� odpowiedni styl architektoniczny, zwanyarchitektur� sterowan� zdarzeniami (ang. event-driven architecture — EDA).

Zdarzenie (ang. event) jest znacz�c� zmian� maj�c� miejsce wewn�trz generatorazdarze� 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�ówekzawiera metadane, a tre�� zawiera faktyczn� informacj� na temat zdarzenia. W prze-ciwie�stwie do tradycyjnych komunikatów, zdarzenia nie posiadaj� okre�lonegomiejsca przeznaczenia.

EDA jest zbli�one do wzorca publikuj/subskrybuj (ang. publish/subscribe), aleposiada tak�e kilka ró�nic, takich jak perspektywa historyczna, która jest uzyskanapoprzez traktowanie zdarze� jako strumieni, a nie wyizolowanych wyst�pie�.

Aby dostosowa� do SOA zdarzeniowy wzorzec wymiany komunikatów, mo�eszzrobi�, co nast�puje:

Zaimplementuj wzorzec Odwrócenie Komunikacji, uzupe�niaj�c SOAo architektur� EDA — mo�esz umo�liwi� us�ugom publikowanie strumieniazdarze�, które w nich wyst�puj�, zamiast bezporednio 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 lubraczej w komponencie brzegowym (poniewa� komponenty te nie s� zorientowanebiznesowo).

Pierwszym komponentem jest propagacja zdarze�. Zdarzenia powinny by�pakowane do formatu uzgodnionego dla inicjatywy SOA (lub zgodnie z kontraktemus�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 jakokonsument us�ug dla zdarze� wys�anych przez inne us�ugi. Pierwszym zadaniemprocedury obs�ugi zdarze� jest filtrowanie przychodz�cych zdarze� pod k�tem

�





Rysunek 5.10. We wzorcu Odwrócenie Komunikacji komponentbrzegowy us�ugi poza „standardowymi” ��daniami akceptujei filtruje przychodz�ce zdarzenia. Kiedy us�uga ma gotow� jak�odpowied lub reakcj� na zdarzenie, komponent brzegowyrównie� pakuje i ekspediuje j� do konsumentów us�ug jakozdarzenie

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 wielewysi�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 celumo�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. Narysunku 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 pozytywnywp�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�adzieus�uga „Opónienia” wci�� posiada interakcje ��danie/Odpowied z us�ugami „Planylotów” i „Rezerwacje”. Je�li us�uga „Opónienia” zidentyfikuje opónienie, mo�espróbowa� zarezerwowa� miejsca w póniejszych lotach dla osób, które nie zd��y�yna przesiadk�.





Rysunek 5.11. Relacje pomi�dzyus�ugami z rysunku 5.9po zastosowaniu wzorcaOdwrócenie Komunikacji.Teraz us�ugi „Pogoda”,„Lotniska” i „Obraz operacyjny”przekazuj� swoje zmianydo 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 konsumentowius�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 bazieSOA. Jak dot�d przygl�dali�my si� prostej stronie tej kwestii, która obejmuje spo-radyczne lub wyizolowane zdarzenia. Ale bardzo silna koncepcja definiowana przezEDA to strumie� zdarze�. Oznacza to, �e nie spogl�dasz na zdarzenie w jegow�asnej postaci, ale raczej na �a�cuch powi�zanych zdarze� w pewnym przedzialeczasowym. Strumienie zdarze� mog� dostarczy� Ci zarówno trendy, jak i perspek-tyw� historyczn�. Dobrze wykorzystane mog� zapewni� Ci wywiad biznesowyi 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, jestwzorzec Potoki Równoleg�e (omówiony w rozdziale 3.). Ta kombinacja mo�e by�zastosowana do dostarczenia implementacji SOA etapowej architektury sterowanejzdarzeniami (ang. staged event-driven architecture — SEDA). W skrócie, SEDAmo�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 sobiez tym problemem zosta� ju� wspomniany — nie stosuj wy��cznie wzorca Odwró-cenie Komunikacji, a raczej po��cz go z innym wzorcem wymiany komunikatówwymienionym w tym rozdziale.

Jedn� z rzeczy, na które nale�y uwa�a� i których nale�y unika� przy korzystaniuz wzorca Odwrócenie Komunikacji, jest b��dne ko�o zdarze�. Ma to miejsce, kiedyjakie� zdarzenie uruchamia �a�cuch zdarze�, który wraca do ród�a pierwotnegozdarzenia i powoduje ponowne uruchomienie tego samego lub podobnego zdarzenia.





Nie spotka�em si� jeszcze z tym w praktyce, ale taka mo�liwo�� istnieje. Sposobemradzenia 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� dotego problemu. Sposobem przeciwdzia�ania jest scentralizowane rejestrowanie przezca�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�oneus�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, sekretemjest stopniowe przechodzenie.

Inny zestaw wyzwa� zwi�zanych z wzorcem Odwrócenie Komunikacji doty-czy szczegó�ów implementacji. Wszak�e wiele infrastruktur SOA (co najbardziejoczywiste, HTTP) nie obs�uguje zdarze� czy transmisji grupowych (multicastów).Zobaczmy, czy uda nam si� przezwyci��y� te przeszkody.

MAPOWANIE TECHNOLOGIIIstnieje kilka opcji mapowania technologii dla implementacji wzorca OdwrócenieKomunikacji.

Pierwsz� opcj�, która wydaje si� równie� najbardziej naturalna, jest zastoso-wanie korporacyjnej magistrali us�ug (ESB). Wi�kszo�� implementacji ESB mo�ezaadaptowa� wszystkie popularne wzorce wymiany komunikatów, w tym publi-kuj/subskrybuj. Listing 5.4 pokazuje, jak mo�na skonfigurowa� subskrypcj� w ApacheServiceMix (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 nainfrastruktur� i wtedy mo�esz skoncentrowa� si� na planowaniu zdarze� oraz innychaktywno�ciach biznesowych.





Mo�esz uzyska� jeszcze luniejsze powi�zania, stosuj�c infrastruktur� wymianykomunikatów (lub ESB), która obs�uguje tematy, cho� nie jest to typowa infrastruk-tura us�ug dla SOA. Tematy s� luniej 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 jestwydawca, to infrastruktura musi zadba� o to, �eby zdarzenia by�y publikowanetylko 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 komponentubrzegowego ka�dej us�ugi. Innymi s�owy, nale�y przygotowa� w�asn� logik� utrzy-mywania subskrypcji i aktywnego wysy�ania ka�dego wygenerowanego zdarzeniado 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 takprawdopodobnie nie wyjdzie za pierwszym razem.

Druga opcja, wed�ug mnie bardziej interesuj�ca, zwi�zana jest z aplikacjamitypu 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 ononatychmiastowo 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órzyzarz�dzaj� subskrypcj� po swojej stronie niezale�nie ode mnie (lune 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, podobniejak wersje formatu JSON, takie jak OData i GData.

Jak wcze�niej wspomniano, element architektury EDA we wzorcu OdwrócenieKomunikacji pozwala traktowa� zdarzenia jako strumie�, a nie jako wyizolowaneinstancje. 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, CEPpolega na badaniu strumieni zdarze� pod k�tem z�o�onych wzorców. Prawdopo-dobnie naj�atwiej b�dzie wyja�ni� to na przyk�adzie.





Czas �ycia zdarzeniaBez 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órymzdarzenie 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�likonsument jest nieobecny, kiedy zdarzenie jest przywo�ywane, to jego problem. W SOArozs�dniej jest pozwoli� na tymczasowe oddzielenie pomi�dzy czasem wywo�aniazdarzenia a czasem jego skonsumowania. Takie tymczasowe oddzielenie umo�liwiazwi�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, zbytdu�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 zdarzejednorazowych (np. nowe zamówienie) jest z regu�y znacznie d�u�sze.

Listing 5.5 pokazuje przyk�adowe zapytanie we wbudowanym silniku CEP, którenapisa�em kilka lat temu (oparte na technologii C# LINQ). Zapytanie to analizujestrumie� 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 okrelonego zdarzeniaw 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.Dost�pnych jest te� kilka opcji na licencji open source, np. Esper firmy EsperTech.

Wzorzec Odwrócenie Komunikacji stanowi dobr� okazj� do wprowadzenia CEPdo projektu, ale nie jest to g�ówny powód korzystania z tego wzorca. Jak zwyklezako�czymy nasz� dyskusj� o wzorcu, badaj�c niektóre motywacje do jego zasto-sowania.




5.4. Wzorzec Saga 165

ATRYBUTY JAKO CIOWE

Odwrócenie Komunikacji to wzorzec o du�ych mo�liwo�ciach. Interakcja opartana znaczeniach pomaga znacz�co zwi�kszy� autonomi� i kompozycyjno�� systemu,a tak�e podnie�� poziom ponownego wykorzystywania elementów wewn�trz systemu.To dla SOA �wietna nowina do tego stopnia, �e Gartner nazwa� po��czenie EDAz SOA „zaawansowanym SOA”. Chocia� trzeba mie� na uwadze wyzwania zwi�zanez implementacj� wzorca Odwrócenie Komunikacji, takie jak skomplikowane debu-gowanie i dodatkowa praca przy projektowaniu zdarze�, jest to istotny wzorzec,który warto mie� w zestawie swoich narz�dzi z uwagi na wszystkie oferowane przezniego korzy�ci.

Tabela 5.4 wskazuje niektóre scenariusze, które mog� sk�oni� Ci� do zastoso-wania wzorca Odwrócenie Komunikacji.

Tabela 5.4. Atrybuty jakociowe wzorca Odwrócenie Komunikacji i przyk�adowescenariusze


Elastyczno�� Oddzielanie Us�ugi powinny posiada� mo�liwie najmniejinformacji o sobie

Ponowne wykorzystanie Interfejsy Wszystkie us�ugi, poza konkretnymi��daniami, które mog� obs�ugiwa�, powinnyobs�ugiwa� kilka typowych interfejsów API

atwo�� wprowadzaniazmian

Dodawanie funkcji Posiadaj�c gotow� now� funkcjonalno��,powiniene� by� w stanie zintegrowa� j�w systemie w czasie krótszym ni� trzytygodnie

Wzorzec Odwrócenie Komunikacji podsumowuje podstawowe wzorce wymianykomunikatów, pokazuj�c, w jaki sposób mo�na w SOA wykorzysta� zdarzenia lubmodel publikuj/subskrybuj. Ostatni z wzorców, którym zajmiemy si� w tym rozdziale,nosi nazw� Saga. Umo�liwia on uzyskanie transakcyjnego zachowania pomi�dzyus�ugami.

5.4. Wzorzec Saga

W rozdziale 2. omawiali�my wzorzec Us�uga Transakcyjna, który zapewnia nieza-wodno�� obs�ugi ��da� przez us�ugi. Jednak zastosowanie tego wzorca rozwi�zujetylko jedn� cz�� uk�adanki. Przyjrzyjmy si� ponownie scenariuszowi z rozdzia�u 2.i zobaczmy, co jeszcze powinni�my zrobi�.

Na rysunku 5.12 przedstawiona zosta�a us�uga „Zamawianie”, przetwarzaj�cazamówienie. Interesuj�ce kwestie pojawiaj� si� tutaj na etapach 2.3 i 2.4. W ramachwewn�trznej transakcji obs�uguj�cej ��danie us�uga „Zamawianie” musi wspó�-pracowa� z dwoma innymi us�ugami: ��da wystawienia rachunku od wewn�trznejus�ugi „Rozliczenia” i sk�ada zamówienia (na cz��ci lub materia�y) w zewn�trznymsystemie „Dostawca”.

Napotkamy tutaj dwa g�ówne problemy. Pomy�l, co si� stanie, kiedy zamiastzatwierdzenia wewn�trznej transakcji na etapie 2.5 us�uga „Zamawianie” zdecyduje





Rysunek 5.12. Przyk�adowy schemat przep�ywu komunikatów w scenariuszue-commerce (konwersuj�cego z us�ug� „Zamawianie”). Fasada wysy�a zamówieniedo us�ugi zamawiania, która nast�pnie zamawia cz�ci w us�udze „Dostawca”i prosi us�ug� „Rozliczenia” o wystawienie rachunku klientowi. Zwró� uwag�, �e ca�aobs�uga komunikatu „Z�o�enie zamówienia” (etap 1.0) odbywa si� w pojedynczejtransakcji lokalnej (etapy od 2.0 do 2.5)

si� przerwa� swoj� (wewn�trzn�) transakcj�. Zastanów si� równie�, w jaki sposóbus�uga zamawiania mog�aby uzyska� zaanga�owanie pozosta�ych us�ug, aby konty-nuowa� swoj� prac� na bazie tego zaanga�owania. Zanim potwierdzisz zamówienieklientowi, mo�esz chcie� uzyska� potwierdzenie od dostawcy, �e zamówione ele-menty zosta�y zarezerwowane dla Ciebie.

PROBLEM

Oczywistym rozwi�zaniem tych dwóch wspomnianych w poprzednim punkcieproblemów jest rozszerzenie wewn�trznej transakcji us�ugi „Zamawianie” na pozo-sta�e us�ugi. Taka rozszerzona transakcja okre�lana jest mianem transakcji rozpro-szonej (ang. distributed transaction).





Wykorzystuj�c transakcje rozproszone, us�uga „Zamawianie” musia�aby wywo-�ywa� zarówno us�ug� „Rozliczenia”, jak i system „Dostawca” w ramach pojedynczejtransakcji. Je�li wszystkie us�ugi zgodzi�yby si� zaanga�owa�, ca�a transakcja by�abyzatwierdzana i wype�niana jednocze�nie. Brzmi to naprawd� �wietnie i mamy nawettechnologi�, która to umo�liwia — technologi� wyprzedaj�c� SOA o wiele lat.

Zawsze jednak istnieje jakie� „ale”. Co je�li dostawca mo�e zako�czy� swoj�cz�� transakcji dopiero po zatwierdzeniu biznesu przez starszego mened�era?Czy mo�esz przytrzyma� swoje wewn�trzne blokady, czekaj�c, a� ten mened�erwróci z wakacji na Bahamach w przysz�ym tygodniu? Prawdopodobnie nie. A co je�lidostawca oka�e si� by� konkurencj�? Móg�by przed�u�a� transakcj�, aby zepsu�Twój biznes — oczekuj�c zako�czenia transakcji przez dostawc�, przytrzymujeszblokady na wewn�trznych zasobach.

Ten konkretny scenariusz mo�e by� zbyt daleko id�cy, ale chodzi o to, �e niemo�esz przyjmowa� za�o�e� dotycz�cych sposobu dzia�ania pozosta�ych us�ug.Dotyczy to szczególnie us�ug, które nie nale�� do Ciebie. O innych powodach uni-kania transakcji wielous�ugowych mo�esz poczyta� w kontek�cie antywzorca Inte-gracja Transakcyjna w rozdziale 8.

Nawet je�li s�dzisz, �e transakcje wielous�ugowe nie s� problematyczne jakokoncepcja, prawdopodobnie i tak zgodzisz si�, �e transakcje d�ugotrwa�e nie s� zbytdobre. Im bardziej konwersacyjna staje si� transakcja pomi�dzy us�ugami, tymbardziej powiniene� my�le� o alternatywach dla transakcji niepodzielnych. Narysunku 5.12 wida� dwa komunikaty wychodz�ce z us�ugi „Zamawianie”, co mo�eby� granic� dla liczby interakcji. Jednak procesy biznesowe mog� czasem obejmo-wa� znacznie bardziej szczegó�owe konwersacje.

Du�a liczba komunikatów przep�ywaj�cych pomi�dzy us�ugami nie jest zalecana,poniewa� zwi�ksza opónienia i mo�liwo�� wyst�pienia b��du. Niemniej jednakma�a liczba interakcji jest ma�o prawdopodobna. Us�ugi rzadko egzystuj� w ca�ko-witej izolacji. Interoperacyjno�� jest jednym z pierwotnych powodów stosowania SOA.Oznacza to, �e musisz obs�u�y� w sposób niezawodny z�o�one interakcje us�ug bez��czenia wszystkiego w jedn� d�ug� transakcj� niepodzieln�.

Podsumujmy teraz nasze problemy.

Jak mo�esz osi�gn�� rozproszony konsensus pomi�dzy us�ugamibez zastosowania transakcji?

My�l�, �e sta�o si� ju� jasne, i� zastosowanie pojedynczej transakcji nie wchodziw gr�. Je�li wszystkie zaanga�owane us�ugi s� pod Twoj� kontrol�, mo�esz rozbi�d�ugotrwa�y proces na kilka etapów, z których ka�dy b�dzie odbywa� si� w osobnejtransakcji. Mniejsze rozproszone transakcje s� z pewno�ci� krokiem w dobrymkierunku, ale wci�� jeste� zwi�zany transakcjami wielous�ugowymi. Poniewa�wszystko nie jest ograniczone do pojedynczej transakcji, masz problemy, takie jakwycofanie efektu pierwszego etapu, je�li co� pójdzie nie tak na trzecim czy czwar-tym etapie.

Inn� opcj� jest takie modelowanie kontraktów, �eby� nigdy nie potrzebowa�tego rodzaju z�o�onych interakcji. Mo�esz zredukowa� interakcje pomi�dzy us�ugami,

?





je�li zwi�kszysz ziarnisto�� tych us�ug. Istnieje jednak ograniczenie co do wielko�cius�ug — nie chcesz przecie� sko�czy� z jedn� monolityczn� us�ug�, która zajmujesi� wszystkim. Ponadto, podobnie jak obiekty, us�ugi musz� by� spójne i stosowa� si�do zasady jednej odpowiedzialno�ci. Je�li tak zrobisz, mo�esz zawrze� nieco interakcjiw granicach us�ugi, ale nadal b�dziesz musia� obs�u�y� interakcje wielous�ugowe,aby zaimplementowa� procesy biznesowe.

Pozostaje Ci wi�c opcja podzielenia interakcji us�ug — procesu biznesowego —na kilka mniejszych etapów i wymodelowanie ich tak, aby powsta�a d�ugotrwa�akonwersacja pomi�dzy us�ugami.

ROZWI�ZANIE

Wzorzec interakcji Saga ma zapewnia� semantyk� i komponenty do obs�ugi d�u-gotrwa�ych konwersacji wspomnianych pod koniec poprzedniego punktu.

Zaimplementuj wzorzec Saga i podziel interakcje us�ug (proces biznesowy)na kilka mniejszych akcji i reakcji biznesowych. Koordynuj konwersacj�i zarz�dzaj ni� poprzez komunikaty i limity czasu.

Hector Garcia-Molina i Kenneth Salem w 1987 r. zdefiniowali poj�cie „saga” jakosposób rozwi�zania problemu d�ugo �yj�cych transakcji bazy danych. Opisali onisag� jako sekwencj� powi�zanych, niewielkich transakcji1. W sadze koordynator(w ich przypadku baza danych) zapewnia zako�czenie z powodzeniem wszystkichzaanga�owanych transakcji. W przeciwnym razie, je�li transakcje si� nie powiod�,koordynator uruchamia transakcje kompensuj�ce, aby skorygowa� cz��ciowewykonanie.

To, co sprawdza�o si� w przypadku baz danych, jeszcze lepiej sprawdza si� dlainterakcji us�ug w SOA. Na rysunku 5.13 przedstawiono sposób, w jaki mo�na zasto-sowa� koncepcj� sagi w SOA. Mo�esz podzieli� d�ugotrwa�� interakcj� mi�dzyus�ugami na poszczególne dzia�ania lub czynno�ci oraz kompensacje (w przypadkuawarii lub b��dów).

Pierwszym komponentem z rysunku 5.13, o którym nale�y wspomnie�, jestinicjator. Inicjator uruchamia wzorzec Saga, tworz�c kontekst, który jest powodemzaistnienia interakcji. Nast�pnie inicjator wysy�a zapytanie do jednej lub kilku pozo-sta�ych us�ug (uczestników) o wykonanie pewnych dzia�a� biznesowych. Uczestnikmo�e si� zarejestrowa� do koordynacji (w zale�no�ci od stopnia formalno�ci imple-mentacji Sagi). Uczestnicy i inicjator wymieniaj� komunikaty oraz ��dania do mo-mentu, a� osi�gn� pewne porozumienie lub b�d� gotowi do zako�czenia interakcji.Wtedy koordynator wysy�a ��dania do wszystkich uczestników (równie� do inicjatora),aby sfinalizowali porozumienie (przygotowali si� do zatwierdzenia) i zatwierdzili je.

Je�li w trakcie interakcji lub fazy finalnej wyst�pi jaki� problem, dzia�ania, któremia�y miejsce, musz� zosta� anulowane. W regularnych transakcjach ACID mo�nato zrobi�, ale w sadze musisz przeprowadzi� czynno�ci koryguj�ce zwane kompen-

1 Hector Garcia-Molina i Kenneth Salem, „Sagas”, w SIGMOD '87: Proceedings of the 1987 ACM SIGMOD

International Conference on Management of Data (1987), 249–59.

�





Rysunek 5.13. We wzorcu Saga konsument us�ugi oraz jedna lub kilka us�ugutrzymuj� d�ugotrwa�� konwersacj� w obr�bie pojedynczego kontekstu(sagi). Kiedy strony osi�gn� pewien konsensus, konwersacjajest zatwierdzana. Jeli w trakcie konwersacji wyst�pi� jakie problemy,interakcja jest przerywana, a zaanga�owane strony wykonuj� czynnocikoryguj�ce (kompensacje). (*Koordynator mo�e by� komponentemsamodzielnym, zewn�trznym w stosunku do konsumenta)

sacj� (ang. compensation), które niekoniecznie b�d� dok�adnym przeciwie�stwemdzia�a� przeznaczonych do anulowania. Je�li w wyniku pierwotnych dzia�a� us�ugaprzekroczy�a pewien próg, mo�e ona nie chcie� anulowania wykonanych czynno�ci.Anulowanie efektu mo�e te� okaza� si� niemo�liwe, np. je�li wycofanie dzia�a�wymaga od us�ugi czego�, co pierwotnie zainicjowa�o podj�cie tych dzia�a� (mo�nato nazwa� op�at� za anulowanie), lub up�yn��o ju� zbyt du�o czasu. Przyk�adowo,je�li wynikiem dzia�ania sagi by�oby wystrzelenie pocisku, kompensacj� stanowi�obyprzerwanie misji i zdetonowanie pocisku w powietrzu — nie mo�na przecie� zawró-ci� pocisku i umie�ci� go z powrotem w wyrzutni.

Wzorzec Saga jest te� czasem okre�lany mianem „Transakcji D�ugotrwa�ej”.To prawda, �e koncepcyjnie mo�esz traktowa� sag� jako pojedyncz� logiczn� jed-nostk� pracy i �e korzysta ona z semantyki transakcyjnej. Jednak saga w rzeczywisto�cinie przestrzega dogmatów transakcyjnych, takich jak niepodzielno�� czy izolacja,g�ównie dlatego, �e interakcja jest rozproszona zarówno w czasie, jak i przestrzeni.Przyk�adowo, kiedy wywo�ujesz kompensacj�, mo�e by� ju� za póno na anulowaniepierwotnej czynno�ci, mog� wi�c wyst�pi� konsekwencje, takie jak op�aty za anu-lowanie albo cz��ciowe dostarczenie. Termin „Saga” dobrze odzwierciedla fakt, �einterakcja jest d�ugotrwa�a, a komunikaty s� powi�zanie.

Spójrzmy, jak móg�by wygl�da� scenariusz zamawiania z rysunku 5.12 przy zasto-sowaniu wzorca interakcji Saga. Na rysunku 5.14 przedstawiono scenariusz, w któ-rym u dostawcy wyst�pi� brak dost�pno�ci zamówionych towarów. W takim przy-padku zarówno zamawianie, jak i rozliczanie musi zosta� anulowane. Musisz równie�powiadomi� fasad�, �e wyst�pi� problem, i poinformowa� dostawc�, �e zamkn��e�interakcj�.





Rysunek 5.14. Scenariusz e-commerce z rysunku 5.12 przemodelowany pod k�temwzorca Saga. Interakcja z us�ug� „Rozliczenia” i systemem „Dostawca” jest terazkoordynowana przez sag�. Us�uga „Zamawianie” mo�e teraz radzi� sobie z problemamiw bardziej wydajny sposób, anuluj�c zamówienie i powiadamiaj�c o tym fasad�,zamiast liczy� na to, �e wszystko b�dzie dobrze

W tej wersji scenariusza zamawiania ze wzorcem Saga wszystkie zaanga�owaneus�ugi („Zamawianie”, „Rozliczenia” oraz system „Dostawca”) wysy�aj� powiado-mienia, czy s� zdolne do wype�nienia sagi, czy nie. Przyk�adowo, system „Dostawca”wysy�a komunikat b��du, aby powiadomi� us�ug� „Zamawianie”, �e mia� problemz przetworzeniem ��dania „z�o�enie zamówienia”. Kiedy komponent koordynatoraw us�udze „Zamawianie” odbiera komunikat o b��dzie, wysy�a ��dania kompensacjido pozosta�ych stron (do us�ug „Zamawianie” i „Rozliczenia”), po czym powiadamiasystem „Dostawca”, �e interakcja zako�czy�a si� obs�u�eniem b��du.

Fasada jest powiadamiana o niepowodzeniu podczas kompensacji us�ugi „Zama-wianie”. Nie jest to zadaniem koordynatora.





W interakcji przedstawionej na rysunku 5.14 konsument us�ug i us�ugi kontroluj�interakcj� wewn�trznie. Dobrym na to sposobem jest zastosowanie wzorca Prze-p�yw Pracy (omówionego w rozdziale 2.), tak aby ka�da us�uga posiada�a wewn�trznyprzep�yw pracy pod��aj�cy za sekwencj� i za ró�nymi �cie�kami interakcji. Innymwzorcem zwi�zanym z Sag� jest wzorzec Rezerwacja (patrz rozdzia� 6.).

Kolejnym podej�ciem przy implementacji wzorca Saga jest zastosowaniezewn�trznego koordynatora dla konwersacji — wi�cej szczegó�ów znajdzieszw kontek�cie omawiania wzorca Orkiestracja w rozdziale 7. Ró�nica semantycznapomi�dzy wewn�trznie koordynowan� implementacj� Sagi a implementacj� koor-dynowan� zewn�trznie jest taka, �e w tej drugiej koordynator posiada „szeroki obraz”tego, co saga próbuje osi�gn��, podczas gdy w koordynacji wewn�trznej mo�eszosi�gn�� koordynacj� bez konieczno�ci posiadania pe�nego obrazu przez któr�-kolwiek us�ug�. Koordynacja wewn�trzna jest bardziej elastyczna, ale trudniejszaw zarz�dzaniu.

G�ównym wysi�kiem przy implementacji wzorca Saga jest podj�cie decyzjiodno�nie dzia�a� biznesowych i kompensacji. Aby okre�li�, jakie mog� by� te dzia-�ania, mo�esz zastosowa� techniki takie jak modelowanie procesów biznesowych.Notacja i modelowanie procesów biznesowych (ang. Business Process Modeling andNotation — BPMN) zosta�a omówiona w jednym z punktów dotycz�cych wzorcaOrkiestracja w rozdziale 7.

Mimo �e g�ówny wysi�ek w implementacji wzorca Saga dotyczy strony bizne-sowej, modelowania procesów biznesowych oraz dzia�a�, które b�d� obs�ugiwa�d�ugotrwa�e konwersacje, to jest te� kilka technologicznych aspektów zwi�zanychz komunikatami i protoko�ami — przyjrzyjmy si� im teraz.


Minimalne wymagania dla wzorca Saga to dodanie komunikatów kompensacyj-nych do wszystkich informuj�cych o stanie komunikatów uczestnicz�cych w sadze.Ponownie nale�y podkre�li�, �e kompensacja mo�e nie by� w stanie anulowa� pier-wotnych dzia�a�, ale musi próbowa� minimalizowa� skutek tych dzia�a�.

Wewn�trzne przetwarzanie komunikatów kompensacyjnych ró�ni si� w zale�-no�ci od tego, co musi zosta� zrobione w celu usuni�cia efektu pierwotnego komu-nikatu. Zazwyczaj lepszym wyj�ciem jest ustawianie statusów „anulowane” ni� usu-wanie rekordów, szczególnie na poziomie bazy danych, poniewa� pierwotne dzia�aniemog�o uruchomi� inne procesy biznesowe i dzia�ania bazuj�ce na tych rekordach.Przyk�adowo, je�li rezultatem komunikatu jest dodanie zamówienia, inna us�ugamog�a ju� wygenerowa� rachunek. S� szanse, �e wygenerowanie rachunku mia�omiejsce w ramach tej samej sagi, ale us�uga „Zamawianie” mo�e o tym nie wiedzie�lub tego nie kontrolowa�. Dokonywanie zmian, które pozostawiaj� po sobie �lad (np.ustawienie statusu „anulowano”), jest lepszym wyj�ciem ni� usuwanie rekordów,poniewa� umo�liwia to r�czne rozwi�zywanie problemów, gdy zachodzi taka potrzeba.Zwró� uwag�, �e w niektórych bran�ach, takich jak bankowo��, prawo obligujeraczej do rejestrowania procesów anulowania jako zmian, a nie do usuwania lub





poprawiania oryginalnych rekordów. (Wi�cej informacji na temat tego, �e nie nale�yusuwa� rekordów, znajdziesz w artykule „Accountants Don’t Use Erasers” autor-stwa Pata Hellanda wyszczególnionym w podrozdziale „Dalsza lektura”).

Kolejnym typem komunikatów istotnym dla wzorca Saga s� komunikaty o nie-powodzeniu. Kiedy masz do czynienia z prost� interakcj� punkt-punkt pomi�dzyus�ugami, odpowied lub reakcja wysy�ane przez wywo�an� us�ug� wystarczaj� doprzekazania istoty problemu. Wywo�uj�cy us�ug� konsument us�ug, który rozumiekontrakt us�ugi, mo�e zorientowa� si�, �e co� jest nie tak, i podj�� odpowiedniedzia�ania. Jednak je�li implementujesz wzorzec Saga, mo�esz mie� wi�cej ni� dwiezaanga�owane strony oraz koordynatora. Koordynator nie ma tak du�ej �wiadomo-�ci biznesowej, jak logika biznesowa us�ugi, ale definiuje komunikaty kontroluj�cew celu zrozumienia statusu interakcji.

Jak pewnie wiesz (lub zd��y�e� si� ju� zorientowa�), us�ugi sieciowe s� postrze-gane jako podstawowa technologia do implementacji SOA, w czym wzorzec Sagarównie� zbytnio si� nie ró�ni. Stos protoko�ów WS-* wprowadzi� protokó�WS-BusinessActivity jako element WS-Coordination.

Protokó� WS-BusinessActivity posiada dwa warianty:

� Business Agreement with Coordinator Completion (uzgodnienia biznesowedope�niane przez koordynatora) — Koordynator decyduje i powiadamiauczestników, kiedy dope�nia si� ich rola w ramach danego dzia�ania. Takiepodej�cie jest nieco bardziej uporz�dkowane.

� Business Agreement with Participant Completion (uzgodnienia biznesowedope�niane przez uczestników) — Uczestnicy decyduj�, kiedy dope�nia si�ich rola w ramach danego dzia�ania. To podej�cie charakteryzuje si�luniejszymi powi�zaniami oraz kosztem, którym s� zwi�kszone szansena kompensacj�.

WS-BusinessActivity definiuje uporz�dkowany protokó� oraz stany zarówno dlauczestnicz�cych us�ug, jak i koordynatora. Definiuje równie� dwa rodzaje koor-dynatorów:

� AtomicOutcome — Wszyscy uczestnicy musz� zamkn�� (zatwierdzi�) interakcj�lub przeprowadzi� kompensacj�.

� MixedOutcome — Koordynator zajmuje si� ka�dym uczestnikiem osobno.

Na rysunku 5.15 przedstawiono przej�cia stanów dla uczestnicz�cych us�ug przyzastosowaniu protoko�u WS-BusinessActivity w wariancie dope�nianym przezuczestników.

Inn� istotn� opcj� technologiczn� s�u��c� do implementacji wzorca Saga jestzastosowanie j�zyka BPEL (ang. Business Process Execution Language) lub jegoimplementacja WS-* znana jako WS-BPEL (lub BPEL4WS w poprzednich wersjach).Ponadto mo�esz równie� zastosowa� silnik orkiestracji niekompatybilny z BPEL.Tego typu mapowanie technologii dotyczy wspomnianej uprzednio koordynacjizewn�trznej i jest opisane bardziej szczegó�owo w kontek�cie wzorca Orkiestracjaw rozdziale 7.





Rysunek 5.15. Schemat stanów z punktu widzenia us�ugi uczestnicz�cejprzy wykorzystaniu protoko�u WS-BusinessActivity w warianciedope�nianym przez uczestników. Przejcia stanów mog� by� wynikiemdecyzji podejmowanych przez us�ug� (linie wykropkowane) lub przezkomunikaty od koordynatora (linie ci�g�e)

ATRYBUTY JAKO CIOWEG�ównym powodem do zastosowania wzorca Saga jest potrzeba zwi�kszenia inte-gralno�ci systemu. Jak wspomniano w poprzednich punktach, transakcje s� pro-blematyczne, kiedy w ogóle mamy do czynienia ze �rodowiskami rozproszonymi,a problem ten jest jeszcze wi�kszy w przypadku SOA. Niemniej jednak nadal chcemymie� mo�liwo�� koordynowania us�ug i posiada� znacz�ce interakcje. Koordynuj�cto zachowanie oraz obs�ug� b��dów, mo�esz wprowadzi� niezawodne, przewidywalnei d�ugotrwa�e konwersacje.

W �rodowisku rozproszonym stosunkowo ci��ko jest przewidzie�, jaki b�dziewynik z�o�onej interakcji. Dotyczy to szczególnie innych wzorców, takich jakOdwrócenie Komunikacji (omówiony w podrozdziale 5.3). Wzorzec Saga wprowa-dza do interakcji pewn� kontrol� i pilnuje, aby wynik z�o�onej interakcji odpowiada�znanym schematom (dope�niony lub skompensowany).

Rezultatem zwi�kszonej przewidywalno�ci jest równie� wzrost poprawno�ci.Kiedy mo�esz przewidzie� zachowanie systemu, �atwiej jest przygotowa� testy sys-temu, aby zweryfikowa�, czy otrzymasz po��dany wynik.

Tabela 5.5 prezentuje przyk�adowe scenariusze dla wymienionych atrybutówjako�ciowych.

Napisanie logiki kompensacji jest do�� skomplikowane. Wraz z up�ywem czasuliczba zmian w us�udze mo�e sta� si� do�� du�a, co utrudnia osi�gni�cie przewidy-walno�ci, kiedy próbujesz anulowa� wczesne zmiany. Jednym ze sposobów radzeniasobie z t� kwesti� jest zaimplementowanie wzorca Rezerwacja, o którym przeczy-tasz w nast�pnym rozdziale.





Tabela 5.5. Atrybuty jakociowe wzorca Saga i przyk�adowe scenariusze


Integralno�� Poprawno�� Bez wzgl�du na warunki zamówienieprzetwarzane przez system zostanie rozliczone

Integralno�� Przewidywalno�� W normalnych warunkach szanse wystawieniakonsumentowi rachunku za anulowanezamówienie wynosz� mniej ni� 5%

Niezawodno�� Obs�uga b��dów Po wznowieniu dzia�ania po przerwaniukomunikacji wszystkie procesy, które zosta�yzak�ócone, pozostan� spójne

5.5. Podsumowanie

Jedn� z cech wyró�niaj�cych wszystkie wzorce przedstawione w tym rozdzialejest to, �e nie s� one nowe. Wszystkie wzorce interakcji wyprzedzaj� SOA o wiele lat.Mimo to po�wi�ci�em kilkadziesi�t stron na ich prezentacj�, zamiast po prostuodwo�a� si� do znakomitej ksi��ki Hohpe’a i Woolfa Enterprise Integration Patterns,która równie� je omawia. Powodem tego jest fakt, �e chocia� s� to stosunkowo prostei dobrze znane wzorce, to ka�dy z nich ma pewne aspekty, które nieco go komplikuj�przy próbie implementacji w SOA i dostosowaniu do zasad tej architektury.

� ��danie/Odpowied� — Ten wzorzec dotyczy komunikacji synchronicznej,ale w SOA lepiej jest stosowa� interakcje oparte na dokumentach. Ró�ni si�to znacznie od interakcji opartych na wywo�aniach RPC, które s� standardemkomunikacji synchronicznej w tradycyjnych architekturach rozproszonych.

� ��danie/Reakcja — Wzorzec ten implementuje komunikacj� asynchroniczn�.Ponownie jest to prosty wzorzec, ale jego implementacja mo�e by�skomplikowana, je�li masz do czynienia z konsumentami nieobs�uguj�cymiwywo�a� zwrotnych.

� Odwrócenie Komunikacji — Ten wzorzec implementuje zdarzenia, ale mo�eprzysporzy� kilka problemów, takich jak implementacja na bazie protoko�ówtransportowych nieobs�uguj�cych zdarze�. Innym interesuj�cym aspektemjest dostarczanie strumienia zdarze�.

� Saga — Saga jest sposobem, aby us�ugi mog�y osi�gn�� rozproszony konsensusbez polegania na transakcjach rozproszonych.

Dwa kolejne rozdzia�y po�wi�cone s� mniej podstawowym wzorcom interakcji.Niektóre z nich s� komplementarne do omówionych tutaj wzorców. Jest to np. wzo-rzec Rezerwacja z rozdzia�u 6., który uzupe�nia wzorzec Saga, czy te� wzorzecZagregowane Raportowanie z rozdzia�u 7., który korzysta z wzorca OdwrócenieKomunikacji. Pozosta�e wzorce, którymi si� zajmiemy, takie jak wzorzec FasadaKompozytowa z rozdzia�u 6., dotycz� aspektów interakcji i agregacji wykraczaj�cychpoza bazowe wzorce wymiany komunikatów.




5.6. Dalsza lektura 175

5.6. Dalsza lektura

Gregor Hohpe i Bobby Woolf, Enterprise Integration Patterns: Designing, Building,and Deploying Messaging Solutions (Addison-Wesley Professional, 2003).Ta ksi��ka omawia w ogólnym kontek�cie podstawowe wzorce integracyjne,z których wiele ma równie� zastosowanie w SOA.

Interfejsy API Google Data, http://code.google.com/apis/gdata/overview.html.Protokó� GData (ang. Google Data Protocol) jest przyk�adem dokumentowo-cen-trycznego protoko�u interakcji z us�ugami.

WZORZEC ODWRÓCENIE KOMUNIKACJI

Arnon Rotem-Gal-Oz, „Bridging the Gap Between BI & SOA”, http://www.infoq.com/articles/BI-and-SOA.Ten artyku� pokazuje zastosowanie wzorca Odwrócenie Komunikacji (a tak�ewzorca Zagregowane Raportowanie).

Matt Welsh, „SEDA: An Architecture for Highly Concurrent Server Applications”,http://www.eecs.harvard.edu/~mdw/proj/seda/.Po��czenie wzorców Odwrócenie Komunikacji oraz Potoki Równoleg�e jestimplementacj� SEDA dla SOA.

WZORZEC SAGA

Pat Helland, „Accountants Don’t Use Erasers”, Pat Helland’s WebLog, http://blogs.msdn.com/b/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx.Pat Helland obja�nia zalety zachowywania poprzednich stanów.








Skorowidz

AACID, 56, 178administracja, 44agent stra�nika, 98agregacja us�ug, 223aktory Akka, 83antywzorce, 233, 235

Integracja Transakcyjna,236, 249

konsekwencje, 235Nanous�uga, 236, 242przyczyny, 235refaktoryzacja, 235Stare Nawyki, 236, 254Supe�, 236, 239znane wyj�tki, 235

ApacheHadoop, 296Santuario, 109

APP, 149, 163AppFabric, 45, 46architektura

n-warstwowa/n-poziomowa, 255

oprogramowania, 26sterowana zdarzeniami,

Patrz EDAzorientowana na us�ugi,

Patrz SOAataki

cross-site request forgery,111

cz�owiek po�rodku, 106typu DoS, 104wstrzyknicie SQL, 118wstrzyknicie XPath, 118XDoS, 118

ATAM, 303

atrybuty jako�ciowe, 262, 301bezpiecze�stwo, 104Bezpieczna

Infrastruktura, 117Bezpieczne Komunikaty,

111czynnik jako�ciowy, 302Dostawca To�samo�ci, 130dostpno�, 96, 97Fasada Kompozytowa, 193Firewall Us�ugi, 122Host Us�ugi, 46Instancja Us�ugi, 93interesariusz, 302Klient/Serwer/Us�uga, 199Komponent Brzegowy, 68Magistrala Us�ug, 212metryka jako�ciowa

oprogramowania, 302Monitor Us�ugi, 137Oddzielone Wywo�anie, 78Odwrócenie Komunikacji,

165Orkiestracja, 220podczynnik jako�ciowy,

302Potoki Równoleg�e, 83Przep�yw Pracy, 64Rezerwacja, 186Saga, 173scenariusze, 261, 303Stra�nik Us�ugi, 101Us�uga Aktywna, 52, 53Us�uga Przetwarzania

Sieciowego, 88Us�uga Transakcyjna, 59warto� metryczna, 302Wirtualny Punkt

Ko�cowy, 96

wydajno�, 71wymagania, 301wzorce, 303, 304Zagregowane

Raportowanie, 230��danie/Odpowied�, 149��danie/Reakcja, 156

autonomia us�ugi, 30

BBackgroundWorker, 151BAM, 157bezpiecze�stwo, 103

atak cz�owiek po�rodku,106

ataki typu DoS, 104atrybuty jako�ciowe, 104Bezpieczna Infrastruktura,

111Bezpieczne Komunikaty,

106Dostawca To�samo�ci, 131Firewall Us�ugi, 118komunikaty, 107, 112Monitor Us�ugi, 138OWASP, 111rodzaje zagro�e�, 104, 106STRIDE, 104szyfrowanie XML, 110token, 116us�uga, 118wzorzec tokenu

synchronizuj�cego, 111Bezpieczna Infrastruktura,

105, 111, 113atrybuty jako�ciowe, 117IPSec, 115




312 SKOROWIDZ

Bezpieczna Infrastruktura,ESB, 117mapowanie technologii, 113problem, 112rozwi�zanie, 112SSL, 114TLS, 114WS-Security, 115

Bezpieczne Komunikaty, 105,106

Apache Santuario, 109atrybuty jako�ciowe, 111mapowanie technologii, 109problem, 106rozwi�zanie, 107XML Encryption, 109XML Signatures, 109

bezpo�rednie pod��czeniebazy danych, 33

big data, 283, 293Hadoop, 296Host Us�ugi, 297kategoria relacyjna, 295Komponent Brzegowy, 297kryteria wyboru, 295Nanous�uga, 297przestrze� magazynowa, 295rozwi�zania masowo

równoleg�e, 295SOA, 296Stra�nik Us�ugi, 297us�uga kategoryzacji, 298Us�uga Przetwarzania

Sieciowego, 297Zagregowane

Raportowanie, 297biometria multimodalna, 85BPEL, 172, 219, 220BPM, 218BPMN, 171, 219, 220

CCEP, 163chmura obliczeniowa, 15, 283,

288cechy charakterystyczne,

289Dostawca To�samo�ci, 293

fa�szywe przes�anki, 290hybrydowa, 290Instancja Us�ugi, 293Magistrala Us�ug, 292Monitor Us�ugi, 293Odwrócenie Komunikacji,

293prywatna, 289publiczna, 289SOA, 292Stra�nik Us�ugi, 293us�ugi, 290Wirtualny Punkt Ko�cowy,

293��danie/Reakcja, 293

choreografia, 216CQRS, 229CRM, 61cykl �ycia, 44czas

dostarczenia, Patrz ETA�ycia zdarze�, Patrz TTL

Ddenormalizacja danych, 51DI, 43DoS, 104, 183Dostawca To�samo�ci, 105,

123, 126Active Directory, 129atrybuty jako�ciowe, 130autoryzacja, 125bezpiecze�stwo, 131chmura obliczeniowa, 293emisja tokenów, 128IBM Tivoli Access

Manager, 129infrastruktura klucza

publicznego, 127LDAP, 129mapowanie technologii,

129Oracle Identity Server, 129PingTrust, 129problem, 124rozwi�zanie, 126SAML, 129serwer tokenów, 126

Shibboleth, 129�wiadczenie us�ug, 126uwierzytelnianie, 125

dostpno�, 71, 96, 97DSL, 210dyspozytor, 76dziedziczenie, 43

EEDA, 159ESB, 45, 47, 117, 162, 209,

210, 218ETA, 155etapowa architektura

sterowana zdarzeniami,Patrz SEDA

ETL, 33, 206

Ffa�szowanie, 104Fasada Kompozytowa, 178,

187, 190atrybuty jako�ciowe, 193GateIn, 192host, 190Liferay Portal, 192mapowanie technologii,

191Microsoft SharePoint, 192portlet, 190Practices, 192Prism, 192problem, 187przep�yw zdarze�, 191rozwi�zanie, 189Web-Sphere Portal Server,

192Firewall Us�ugi, 105, 118

atrybuty jako�ciowe, 122mapowanie technologii,

120problem, 118rozwi�zanie, 119WCF, 121

Framework Spring, 46Fuse ESB, 45




SKOROWIDZ 313

GGridbus, 86

HHadoop, 229, 296HATEOAS, 285host, 190Host Us�ugi, 42

administracja, 44AppFabric, 45, 46atrybuty jako�ciowe, 46, 47big data, 297cykl �ycia, 44instalacja, 44konfiguracja, 44mapowanie technologii, 45odwrócenie sterowania, 44problem, 42rozwi�zanie, 43�rodowisko, 44WebLogic, 45WebSphere, 45zasada otwarte-zamknite,

45HSM, 109

Iinfrastruktura

klucza publicznego, 127typu grid, 86

inicjator, 168Instancja Us�ugi, 73, 89

Apache JServ, 92atrybuty jako�ciowe, 93chmura obliczeniowa, 293dyspozytor, 91HAProxy, 92mapowanie technologii, 92NLB Cluster, 92problem, 89punkt ko�cowy, 91rozwi�zanie, 90schemat, 36udostpnianie stanu, 92Windows NLB, 92zastosowanie, 277

integracjaonline, 33oparta na plikach, 33typu punkt-punkt, 32

Integracja Transakcyjna, 236,249

konsekwencje, 250przyczyny, 252refaktoryzacja, 253znane wyj�tki, 254

integracja us�ug, 203ETL, 206Magistrala Us�ug, 203, 204Orkiestracja, 203, 213Zagregowane

Raportowanie, 204, 221integracyjne spaghetti, 32interesariusz, 302interfejs u�ytkownika177, 187,

Patrz równie� UIkompozyt, 190portlet, 190

IoC, 44IPSec, 115

JJava Message Service, 115JAX-RS, 45JAX-WS, 45, 66jednokrotne logowanie,

Patrz SSOjednolity interfejs, 285jzyki

BPEL, 172, 219, 220dziedzinowy, Patrz DSLwzorców, 38

Kklasa wymagalno�ci,

Patrz wydajno�klaster obliczeniowy, 269klasy aktywne, 49Klient/Serwer/Us�uga, 178,

193, 196atrybuty jako�ciowe, 199mapowanie technologii,

196

problem, 194REST, 196rozwi�zanie, 195

kompensacja, 169, 179komponent brzegowy, 36

stra�nika, 98Komponent Brzegowy, 42, 64,

287, 297atrybuty jako�ciowe, 68big data, 297getAll, 67getLast, 67JAX-WS, 66mapowanie technologii, 66problem, 64Restlet, 67rozwi�zanie, 65Turmeric, 67WCF, 66wi�zania, 66zastosowanie, 265

kompozyt, 190komunikaty, 28, 30

bezpiecze�stwo, 107, 112blok danych, 30buforowalne, 286dokumentowo-centryczny,

146dyspozytor, 37funkcje zabezpiecze�, 108idempotentne, 109jednokierunkowe, 77kompensacyjne, 171o niepowodzeniu, 172ochrona, 112nag�ówek, 30pompa, 55punkty ko�cowe, 28skorelowane, 154SOAP, 116sposoby interakcji, 142truj�ce, 59wymiana, 141zdarze�, 145

konsekwencje, 235Integracja Transakcyjna, 250Nanous�uga, 244Stare Nawyki, 255Supe�, 237




314 SKOROWIDZ

konsumenci us�ug, 28, 31, 141,177, 178

Fasada Kompozytowa, 178,187

interfejs u�ytkownika, 177,187

Klient/Serwer/Us�uga, 178,193

Rezerwacja, 177, 178kontrakty, 28, 30

komunikaty, 28koordynator, 179korporacyjne magistrale us�ug,

Patrz ESBkorporacyjny system

kolejkowania, 56

Llekkie kontenery, 46

MMagistrala Us�ug, 203, 204, 207

atrybuty jako�ciowe, 212chmura obliczeniowa, 292ESB, 209ETL, 206magistrala komunikatów,

209magistrala us�ug, 209mapowanie technologii, 209NServiceBus, 212problem, 205publikowanie/subskrypcja,

206rejestrowanie us�ug, 206rozwi�zanie, 206schemat architektoniczny,

207topologie wdro�enia, 208typy implementacji, 209zastosowanie, 272

mapowanie technologiiBezpieczna Infrastruktura,


109

Dostawca To�samo�ci, 129Fasada Kompozytowa, 191Firewall Us�ugi, 120Host Us�ugi, 45Instancja Us�ugi, 92Klient/Serwer/Us�uga, 196Komponent Brzegowy, 66Magistrala Us�ug, 209Monitor Us�ugi, 135Oddzielone Wywo�anie, 77Odwrócenie Komunikacji,

162Orkiestracja, 218Potoki Równoleg�e, 82Przep�yw Pracy, 62Rezerwacja, 184Saga, 171Stra�nik Us�ugi, 99Us�uga Aktywna, 51Us�uga Przetwarzania

Sieciowego, 86Us�uga Transakcyjna, 58Wirtualny Punkt Ko�cowy,

95Zagregowane


mashup, 284maszyna wirtualna, 285MDM, 229metoda analizy kompromisów

architektonicznych, PatrzATAM

Microsoft Message Queuing,115

model us�ugowy, 262Monitor Us�ugi, 105, 131, 134

AmberPoint, 136atrybuty jako�ciowe, 137bezpiecze�stwo, 138chmura obliczeniowa, 293Looking Glass, 135mapowanie technologii,

135problem, 132rozwi�zanie, 134

monitorowanie aktywno�cibiznesowej, Patrz BAM

MVC, 189

NNanous�uga, 236, 242

big data, 297konsekwencje, 244przyczyny, 246refaktoryzacja, 247znane wyj�tki, 249

nawodnienie, 217NServiceBus, 212

Oobci��enie ��daniami, 74obiekt, 28obs�uga

komunikatów, 206��da�, 54

OCP, 45Oddzielone Wywo�anie, 73

Apache ActiveMQ, 77Apache Qpid, 77atrybuty jako�ciowe, 78dyspozytor, 76kolejka, 76mapowanie technologii, 77Microsoft Message Queue,

77problem, 73procedura obs�ugi, 75Progress SonicMQ, 77QoS, 74RabbitMQ, 77rozwi�zanie, 75WCF, 77WebSphere MQ, 77

odmowa us�ugi, Patrz DoSodrzucenie komunikatu, 104odwodnienie, 217Odwrócenie Komunikacji, 143,

156, 160, 240, 253Apache ServiceMix, 162atrybuty jako�ciowe, 165b�dne ko�o zdarze�, 161




SKOROWIDZ 315

chmura obliczeniowa, 293mapowanie technologii, 162obs�uga zdarzenia

biznesowego, 158problem, 157procedura obs�ugi zdarze�,

159propagacja zdarze�, 159rozwi�zanie, 159zastosowanie, 272

odwrócenie sterowania, PatrzIoC

ograniczony poziom gwarancji,182

OOP, 28Orkiestracja, 203, 213, 215,

240, 253atrybuty jako�ciowe, 220BPM, 218ESB, 218jBPM, 218mapowanie technologii,

218problem, 213proces biznesowy, 213rozwi�zanie, 215silnik przep�ywu pracy, 216

o�wiadczenie, 116

Pparametry ogólnej jako�ci

us�ugi, Patrz QoSpiciodziewi�tkowa

dostpno�, 35podej�cie dokumentowo-

centryczne, 145podniesienie uprawnie�, 104podszywanie si, 104portlet, 190posiadaj i klonuj, 65Potoki Równoleg�e, 73, 79

aktory Akka, 83atrybuty jako�ciowe, 83GigaSpaces, 83mapowanie technologii, 82problem, 79przetwarzanie, 80

rozwi�zanie, 80skalowalno�, 82zastosowanie, 268

potwierdzanie odbioru ��da�,76

problemBezpieczna Infrastruktura,


106Dostawca To�samo�ci, 124Fasada Kompozytowa, 187Firewall Us�ugi, 118Host Us�ugi, 42Instancja Us�ugi, 89Klient/Serwer/Us�uga, 194Komponent Brzegowy, 64Magistrala Us�ug, 205Monitor Us�ugi, 132Oddzielone Wywo�anie, 73Odwrócenie Komunikacji,

157Orkiestracja, 213Potoki Równoleg�e, 79Przep�yw Pracy, 60Rezerwacja, 179Saga, 166Stra�nik Us�ugi, 96Us�uga Aktywna, 48Us�uga Przetwarzania


93Zagregowane


proces biznesowy, 213, 214programowanie

kontraktowe, 61obiektowe, Patrz OOPwizualne, 62

protokó�APP, 149, 163IPSec, 115RTP, 268SSL, 114

TCP, 119TLS, 114UDP, 119WS-BusinessActivity, 172WS-Security, 115WS-Trust, 130

Przep�yw Pracy, 42, 59, 240atrybuty jako�ciowe, 64BizTalk, 62jBPM, 62mapowanie technologii, 62problem, 60rozwi�zanie, 60silnik przep�ywu pracy, 62Workflow Foundation, 62

przetwarzanie rozproszone,291

przyczyny, 235Integracja Transakcyjna,

252Nanous�uga, 246Stare Nawyki, 256Supe�, 238

pull, 156, 163pu�apki SNMP, 99punkt ko�cowy, 30, 36, 211,

223URI, 284

push, 156, 163

QQoS, 74

RRDBMS, 222refaktoryzacja, 235

Integracja Transakcyjna,253

Nanous�uga, 247Stare Nawyki, 256Supe�, 239

regulacja, 31replikowane repozytorium, 285REST, 147, 283, 284

buforowalno�, 285HATEOAS, 285




316 SKOROWIDZ

RESTkod na ��danie, 285komunikacja bezstanowa,

285mapowanie na SOA, 288ograniczenia, 284, 286RESTful SOA, 287URI, 284zasób, 284

RESTful, 163SOA, 287

Restlet, 67Rezerwacja, 177, 178

atrybuty jako�ciowe, 186bezpo�rednia, 181, 186dodatkowe wywo�ania

sieciowe, 183domy�lna, 181, 186EJB 3.0, 184elementy ryzyka, 183mapowanie technologii, 184odmowa us�ugi, 183ograniczony poziom

gwarancji, 182problem, 179rezerwacja, 180rozwi�zanie, 180sprawdzanie wa�no�ci, 181uniewa�nienie, 181zakleszczenie, 183zastosowanie, 275

rozwi�zanieBezpieczna Infrastruktura,


107Dostawca To�samo�ci, 126Fasada Kompozytowa, 189Firewall Us�ugi, 119Host Us�ugi, 43Instancja Us�ugi, 90Klient/Serwer/Us�uga, 195Komponent Brzegowy, 65Magistrala Us�ug, 206Monitor Us�ugi, 134Oddzielone Wywo�anie, 75Odwrócenie Komunikacji,

159

Orkiestracja, 215Potoki Równoleg�e, 80Przep�yw Pracy, 60Rezerwacja, 180Saga, 168Stra�nik Us�ugi, 98Us�uga Aktywna, 49Us�uga Przetwarzania


94Zagregowane


równowa�enie obci��enia, 72RPC, 30, 145RTP, 268

SSaaS, 260Saga, 143, 165, 253, 273

atrybuty jako�ciowe, 173BPEL, 172inicjator, 168kompensacja, 169mapowanie technologii,

171problem, 166rozwi�zanie, 168WS-BusinessActivity, 172zewntrzny koordynator,

171SAML, 129scenariusze, 303

bodziec, 303kontekst, 303odpowied�, 303

SEDA, 161SEI, 27serializacja, 244silnik przep�ywu pracy, 216

nawodnienie, 217odwodnienie, 217

skalowalno�, 71skalowanie, 91

SLA, 31, 93SOA, 13, 25, 27, 262

antywzorce, 233, 235autoryzacja, 125bezpiecze�stwo, 103, 104big data, 296chmura obliczeniowa, 15,

292definicja, 27inicjatywy, 34komponenty, 29komunikaty, 28, 30konsument us�ugi, 28, 31kontrakty, 28, 30korzy�ci architektoniczne,

31korzy�ci biznesowe, 34�ad organizacyjny, 131mapowanie REST, 288mity, 29narzdzia monitoringowe,

136obs�uga zdarzenia

biznesowego, 158ograniczenia

architektoniczne, 286punkty ko�cowe, 28, 30regulacje, 31relacje, 29REST, 284RESTful, 287us�ugi, 28, 30uwierzytelnianie, 125wydajno�, 71wzorce, 35zarz�dzalno�, 103, 104

split brain, 95SRP, 65SSL, 114SSO, 194standard IEEE1061, 301Stare Nawyki, 236, 254


stra�nik, 99




SKOROWIDZ 317

Stra�nik Us�ugi, 73, 96agent stra�nika, 98atrybuty jako�ciowe, 101big data, 297CA Unicenter Agent SDK,

100chmura obliczeniowa, 293HP OpenView, 100IBM Tivoli, 100komponent brzegowy

stra�nika, 98mapowanie technologii, 99Microsoft Operations

Manager, 100Nagios, 99problem, 96rozwi�zanie, 98samouzdrawianie, 99stra�nik, 99Universal Agent, 100zastosowanie, 278

STRIDE, 104strumie� zdarze�, 161stwierdzenie, 116Supe�, 236, 239


systemyenterprise, 32przetwarzania

wewntrznego, 61stovepipe, 32warstwowy, 285zarz�dzania procesami

biznesowymi, Patrz BPMzarz�dzania relacjami z

klientami, Patrz CRMzarz�dzania relacyjn� baz�

danych, Patrz RDBMS

TTCP, 119TLS, 114tokeny

bezpiecze�stwa, 116emisja, 128

serwer, 126transportowanie, 129

transakcjeACID, 56, 178blokada pesymistyczna, 250dwufazowego

potwierdzenia, Patrztransakcje rozproszone

gwarancje, 178izolacja, 250niepodzielno�, 249rozproszone, 58, 166, 250spójno�, 249trwa�o�, 250wielous�ugowe, 167

TTL, 164Turmeric, 67, 68

UUDP, 119UI, 35, Patrz równie� interfejs

u�ytkownikaujawnienie informacji, 104Us�uga Aktywna, 42, 48

atrybuty jako�ciowe, 53atrybuty jako�ciowe, 52mapowanie technologii, 51problem, 48rozwi�zanie, 49

Us�uga PrzetwarzaniaSieciowego, 73, 84, 269

Alchemi, 87atrybuty jako�ciowe, 88big data, 297Gridbus, 86GridGain, 88Hazelcast, 88mapowanie technologii, 86problem, 84rozwi�zanie, 85zastosowanie, 270

Us�uga Transakcyjna, 42, 53ActiveMQ, 58Apache ServiceMix, 58atrybuty jako�ciowe, 59koperta transakcyjna, 55mapowanie technologii, 58

Microsoft Message Queue,58

pompa komunikatów, 55problem, 54rozwi�zanie, 55schemat przep�ywu dla

systemu e-commerce, 57Service Broker, 58transakcja rozproszona, 58WebSphere ESB, 58WebSphere MQ, 58

us�ugi, 28, 30, 33, 263administracja, 44agregacja, 223alokacja, 248antywzorce, 235autonomia, 30, 48bezpiecze�stwo, 118biznesowe, 264Bramka E-mail, 266cykl �ycia, 44czarnej listy, 89duplikowanie, 65ESB, 45firewall, 119funkcje wspieraj�ce, 44Host Us�ugi, 42instalacja, 44instancja, 37integracja, 203interakcja, 205interakcje g�osowe, 221Kalkulator, 242kategoryzacji, 298klasyfikacje, 221klienci, 221Komponent Brzegowy, 64konfiguracja, 44konsumenci, 28, 141, 177,

178odmowa, 104, 183przedstawiciele handlowi,

221Przep�yw Pracy, 59RESTful, 163serwer proxy, 190skalowalne, 90skalowanie, 91




318 SKOROWIDZ

us�ugiSOA, 264�rodowisko, 44transakcyjna, 55Us�uga Aktywna, 48Us�uga Przetwarzania

Sieciowego, 84Us�uga Transakcyjna, 53wzorce, 42zamówienia, 221

uzgodnienia na poziomie us�ug,Patrz SLA

WWCF, 66, 77, 121, 252wi�zania, 66Wirtualny Punkt Ko�cowy, 73,

93atrybuty jako�ciowe, 96chmura obliczeniowa, 293Fuse ESB, 95HAProxy, 95mapowanie technologii, 95Mule, 95problem, 93rozwi�zanie, 94warianty wzorca, 94

WS-AtomicTransaction, 58WS-BusinessActivity, 58, 172

rodzaje koordynatorów,172

WS-Coordination, 58wspó�bie�no�, 79WS-ReliableMessaging, 58WS-Resource Framework, 88WS-Security, 115WS-Trust, 130wstrzykiwanie zale�no�ci,

Patrz DIwydajno�, 71

dostpno�, 71Instancja Us�ugi, 73, 89Oddzielone Wywo�anie, 73opó�nienia, 71Potoki Równoleg�e, 73, 79przepustowo�, 71

równowa�enie obci��enia,72

skalowalno�, 71Stra�nik Us�ugi, 73, 96Us�uga Przetwarzania

Sieciowego, 73, 84Wirtualny Punkt

Ko�cowy, 73, 93wzorce, 73

wymaganiafunkcjonalne, 301niefunkcjonalne, 301

wymiana komunikatówOdwrócenie Komunikacji,

143, 156Saga, 143, 165��danie/Odpowied�, 142,

143��danie/Reakcja, 142, 149

wzorce, 13, 35architektoniczne, 14, 24atrybuty jako�ciowe, 37,

303, 304Bezpieczna Infrastruktura,

105, 111, 113Bezpieczne Komunikaty,

105, 106Dependency Injection, 46Dostawca To�samo�ci,

105, 123, 126dyspozytor, 36Fasada Kompozytowa, 178,

187, 190Firewall Us�ugi, 105, 118fundamentów, 41Host Us�ugi, 42Instancja Us�ugi, 36, 73,

89, 277jzyk, 38kategorie, 39Klient/Serwer/Us�uga, 178,

193, 196Komponent Brzegowy, 42,

64, 265Magistrala Us�ug, 203,

204, 207, 272mapowanie technologii, 37

Model-Widok-Kontroler,189

Monitor Us�ugi, 105, 131,134

MVC, 13nazwa opisowa, 35Oddzielone Wywo�anie, 73Odwrócenie Komunikacji,

143, 156, 160, 272Orkiestracja, 203, 213, 215Potoki Równoleg�e, 73, 79,

268problem, 36Przep�yw Pracy, 42, 59Rezerwacja, 177, 178, 275rozwi�zanie, 36Saga, 143, 165, 273Stra�nik Us�ugi, 73, 96, 278struktura, 35strukturalne, 41token synchronizuj�cy, 111Us�uga Aktywna, 42, 48Us�uga Przetwarzania

Sieciowego, 73, 84, 270Us�uga Transakcyjna, 42,

53Wirtualny Punkt Ko�cowy,

73, 93wydajno�ci, 72Zagregowane

Raportowanie, 204, 221,224

��danie/Odpowied�, 142,143, 152

��danie/Reakcja, 142, 149

XXML Encryption, 109XML Signatures, 109

ZZagregowane Raportowanie,

204, 221, 224, 257atrybuty jako�ciowe, 230big data, 229, 297Hadoop, 229




SKOROWIDZ 319

Zagregowane Raportowaniemapowanie technologii,

229modu� wewntrzny

danych, 224problem, 221przetwarzanie danych, 226punkt ko�cowy, 223rozwi�zanie, 223sposoby dostarczania

danych, 225zakleszczenie, 183zarz�dzalno�, 103, 104

Dostawca To�samo�ci, 123Monitor Us�ugi, 131

zarz�dzanie danymireferencyjnymi, Patrz MDM

zasadajednej odpowiedzialno�ci,

Patrz SRPotwarte-zamknite,

Patrz OCP

podstawienia Liskov,Patrz programowaniekontraktowe

zasób, 284zdalne wywo�anie procedury,

Patrz RPCzdarzenie, 159

b�dne ko�o, 161czas �ycia, 164procedura obs�ugi, 159propagacja, 159strumie�, 161z�o�one przetwarzanie,

Patrz CEPznane wyj�tki, 235

Integracja Transakcyjna,254

Nanous�uga, 249Stare Nawyki, 257Supe�, 241

zupa obiektów, 33

��danie/Odpowied�, 142, 143,

152atrybuty jako�ciowe, 149mapowanie technologii,

146problem, 143rozwi�zanie, 144

��danie/Reakcja, 142, 149Apache Axis2, 154atrybuty jako�ciowe, 156BackgroundWorker, 151chmura obliczeniowa, 293mapowanie technologii,

154problem, 150rozwi�zanie, 152semantyka interakcji, 153




320 SKOROWIDZ




http://program-partnerski.helion.pl/page54916~/

Documents

Tytuł oryginału: SOA Patterns - Alt Control Delete › download › wzosoa.pdf · Rozdzia 1. Rozwizywanie problemów SOA za pomoc wzorców 25 1.1. Definicja architektury oprogramowania