Kompozycja usług. Tomasz Pawlak. Biznesowe Systemy Rozproszone

Kompozycja usług Tomasz Pawlak

2 Plan prezentacji Wprowadzenie Kompozycja usług dawniej i dziś Modele kompozycji usług Związki koordynacji z kompozycją Wprowadzenie do BPEL

2 Plan prezentacji Wprowadzenie Kompozycja usług dawniej i dziś Modele kompozycji usług Związki koordynacji z kompozycją Wprowadzenie do BPEL Za tydzień

3 Czym jest kompozycja usług?

3 Czym jest kompozycja usług? Sposób na łączenie usług prostych w usługi złożone Dlaczego? Sposób radzenia sobie ze złożonością Usługi proste Mały podzbiór funkcjonalność całego systemu Możliwość ponownego wykorzystania Ukrycie szczegółów wykonywanych operacji Czarna skrzynka Kompozycja usług złożonych Działanie na wyższych poziomie abstrakcji Pominięcie szczegółów operacji

4 Zapanować nad złożonością System zamówień Dostawca Inny dostawca

4 Zapanować nad złożonością Usługi internetowe Różne interfejsy! System zamówień Dostawca Inny dostawca

4 Zapanować nad złożonością Usługi internetowe Różne interfejsy! System zamówień Klient usługi Klient usługi Różne Implementacje klienta Dostawca Inny dostawca

4 Zapanować nad złożonością Pierwszy poziom kompozycji System zamówień Klient usługi Klient usługi Dostawca Inny dostawca Ujednolicenie interfejsów

4 Zapanować nad złożonością System zamówień Klient usługi Klient usługi Dostawca Inny dostawca

4 Zapanować nad złożonością Łańcuch dostaw Planowanie produkcji Księgowość System zamówień Klient usługi Klient usługi Dostawca Inny dostawca

4 Zapanować nad złożonością Drugi poziom kompozycji Łańcuch dostaw Planowanie produkcji Księgowość System zamówień Klient usługi Klient usługi Dostawca Separacja odpowiedzialności Inny dostawca

5 Zysk z kompozycji usług Usługi logicznie izolują Funkcjonalności Kod różnych dostawców Ukrywają szczegóły implementacyjne Dzięki temu Wymuszona modularyzacja Trudniej stworzyć spaghetti code Trudniej wykorzystać haki i nieudokumentowaną funkcjonalność Klient usługi nie zna implementacji usługi

Wymagania wynikające z kompozycji usług dotyczące infrastruktury (1) 6 Nadrzędny cel: Uprościć definicję, uruchomienie, utrzymanie usług złożonych z innych usług Podejście ręczne: Wsparcie dla popularnych języków programowania Programiści niechętnie zmieniają technologie Systemy wykorzystują istniejący kod Klienci usług pisani w języku, w którym powstał system Narzędzia Generatory kodu z definicji interfejsu Rozszerzenia języka programowania i biblioteki Umożliwiają kompozycję usług na poziomie języka programowania Ukrywają fakt rozproszenia usług

7 Wymagania wynikające z kompozycji usług dotyczące infrastruktury (2) Wykorzystanie automatyzacji: Systemy modelowania procesów biznesowych Np.: systemy Workflow Wsparcie dla standardów Automatyczne generowanie odpowiednich dokumentów Automatyczne wczytywanie i interpretacja dokumentów Wykonanie procesu biznesowego Selekcja usług Obsługa rozproszonych transakcji Publikowanie interfejsów

8 Wymagania wynikające z kompozycji usług dotyczące infrastruktury (3) Dzisiejsza infrastruktura wspiera oba podejścia Ręczne podejście Dobre do małych projektów Dla programistów niezaznajomionych z technologią Przy konieczności szybkiej implementacji Wykorzystanie automatyzacji Daje pogląd na cały system bez wchodzenia w detale techniczne Łatwość utrzymania Konieczność poznania technologii

8 Wymagania wynikające z kompozycji usług dotyczące infrastruktury (3) Dzisiejsza infrastruktura wspiera oba podejścia Ręczne podejście Dobre do małych projektów Dla programistów niezaznajomionych z technologią Przy konieczności szybkiej implementacji Wykorzystanie automatyzacji Daje pogląd na cały system bez wchodzenia w detale techniczne Łatwość utrzymania Konieczność poznania technologii Dalej: Będziemy zajmować się automatyzacją

9 Główne elementy infrastruktury (1) Schemat kompozycji (ang. composition schema) Model kompozycji wyrażony w języku kompozycji Łączenie usług Ograniczenia kolejnościowe na wykonanie usług (koordynacja) Sposób uzyskania parametrów wywołań usług Język kompozycji Język specyficzny dla dziedziny (ang. domain-specific language)

10 Główne elementy infrastruktury (2) Środowisko programistyczne Graficzny interfejs użytkownika Łatwiej interpretować schematy niż kod Możliwość specyfikacji schematu kompozycji Np.: w formie grafu Automatyczne tłumaczenie Reprezentacji graficznej w kod Kodu w reprezentację graficzną

11 Główne elementy infrastruktury (3) Środowisko czasu uruchomienia Silnik kompozycji Wykonuje logikę biznesową złożonej usługi Wywołania usług składowych Instancja kompozycji Pojedyncze wykonanie złożonej usługi

12 Kompozycja usług dawniej i dziś

13 Kompozycja komponentów oprogramowania wymagania Precyzyjny opis Funkcjonalność usługi Semantyka Interfejs Protokoły komunikacyjne Najlepiej wykorzystać standardy Przenośność między systemami Uniknięcie problemów, które rozwiązali twórcy standardu Łatwość utrzymania

14 Systemy Workflow (1) System klasy Enterprise Application Integration (EAI) Wsparcie dla kompozycji aplikacji Wielu dostawców Wiele technologii Modelowanie procesów biznesowych (workflow)

15 Systemy Workflow (2) Mało założeń dotyczących integrowanych systemów Brak standaryzacji W praktyce konieczność łączenia z innym middleware Np.: z middleware nastawionym na wiadomości (MOM) Brak standardowego modelu kompozycji Konieczność przygotowania adapterów Specyficzne dla aplikacji i dostępnych interfejsów Np.: Komunikacja sieciowa lub przez standardowe we/wy Rozwiązania konkretnego producenta

16 Systemy Workflow (3) Efekt: Duża elastyczność Duża złożoność Osobny adapter dla każdego komponentu Wysoki koszt wdrożenia Wysoki koszt utrzymania Np.: dodania nowego komponentu Komponenty nie mogą być swobodnie Łączone Zastępowane

17 Przykład złożoności kompozycji w Workflow System workflow Wstawia zadania Do odpowiednich kolejek W odpowiednim czasie Adapter Pobranie zadania z kolejki API systemu Workflow Formaty wiadomości Protokoły Uruchomienie zadania w adaptowanym komponencie API komponentu

18 Kompozycja usług internetowych Silny podział na komponenty o określonej funkcjonalności Interfejsy usług Jednoznacznie zdefiniowane Standardowy język opisu interfejsu Semantyka Częściowo zawarta w katalogach usług Ustandaryzowany sposób zapisu Protokoły komunikacji Standardowy format wiadomości Standardowy protokół komunikacji

19 Usługi internetowe nie rozwiązują wszystkich problemów! (1) Dane są dwie usługi A: komunikacja RPC B: komunikacja oparta o wymianę dokumentów Aby zintegrować obie usługi Należy uspójnić model komunikacji

20 Usługi internetowe nie rozwiązują wszystkich problemów! (2) Standardowy Sposób opisu interfejsu Protokół komunikacyjny Sposób publikowania informacji o usługach Nie sprawi, że usługi są ze sobą kompatybilne Zaleta: Nadal występują problemy na poziomie aplikacyjnym Programista jest odciążony od integracji infrastruktury

Podobieństwo kompozycji w systemach Workflow i usługach internetowych 21 Cechy wspólne adapterów w Workflow i usług internetowych Integracja systemów/aplikacji Adapter/WS musi znać szczegóły integrowanych systemów Dodatkowa warstwa abstrakcji Ukrywa szczegóły systemów Z zewnętrznej perspektywy systemy to czarne skrzynki Ujednolica interfejs dostępowy System może udostępniać swoje usługi różnymi interfejsami Np.: komunikacja RPC i wymiana dokumentów Odpowiednik adapterów w middleware Różnice Adapter w Workflow Przygotowywany przez integratora systemów Brak standardów Usługa internetowa Przygotowywania przez dostawców komponowanych systemów Ograniczona standardami

22 Modele kompozycji usług

23 Podstawowe pojęcia Proces Schemat kompozycji Instancja procesu Konkretne wykonanie procesu Orkiestracja Fragment procesu specyfikujący kolejność operacji na usługach

24 Wymiary modelu kompozycji usług (1) Model komponentowy Definicja natury komponowanych elementów Założenia dotyczące komponentów Model orkiestracji Definicja porządku wykonania usług Np.: Diagram aktywności Sieć Petriego Rachunek π Maszyna stanów Hierarchia aktywności Reguły

25 Wymiary modelu kompozycji usług (2) Model danych i przepływu danych Specyfikacja formatu danych Specyfikacja wymiany danych między komponentami Model selekcji usługi Sposób wykonania wiązania Dynamicznego Statycznego Np.: Jak konkretna usługa jest wybrana jako komponent

26 Wymiary modelu kompozycji usług (3) Model transakcji Połączenie elementów modelu w transakcje Model obsługi błędów Definicja sposobu obsługi wyjątkowych sytuacji Np.: błędów zgłoszonych przez usługi składowe Bez przerwania pracy usługi złożonej

27 Model komponentowy (1) Wiele możliwych poziomów szczegółowości Poziom najbardziej szczegółowy Komponenty implementują specyficzny zbiór standardów WS-* Założenia o standardach ograniczają różnorodność Łatwiejsza kompozycja Poziom ogólny Mało założeń dotyczących komponentów Np.: Komponenty wymieniają wiadomości XML Komunikacja (a)synchroniczna Większa heterogeniczność Kompozycja podobna do systemów workflow Konieczność adaptacji usług

28 Model komponentowy (2) Rozwiązanie pośrednie Wspierać różne modele w systemie Dostarczyć funkcjonalność pomocniczą dla komponentów nie pasujących do żadnego modelu Ale uwaga! Zbyt wiele możliwości = brak możliwości Utrzymanie wielu modeli Wyższe koszty utrzymania

29 Model komponentowy (3) Popularne rozwiązanie: BPEL Założenie: Komponenty są usługami opisanymi w WSDL Adresacja usług przez WS-Addressing Transakcje wyrażone w WS-Transaction Wskazanie na elementy XML przez XPath

30 Model orkiestracji Porządek wykonania usług Warunki wykonania poszczególnych operacji Kolejność wykonania operacji

31 Model orkiestracji diagram aktywności 1 Cechy Modelowanie aktywności pojedynczej usługi Usługi składowe występują jako pojedyncze bloczki Naturalna specyfikacja kolejności wykonania Odzwierciedla sposób programowania Typy operacji Powiadomienia Komunikacja jednokierunkowa Send Wiadomości na zewnątrz usługi Operacja nieblokująca Receive Wiadomość z zewnątrz usługi Operacja blokująca, usługa czeka na wiadomość Wywołania synchroniczne Komunikacja dwukierunkowa, blokująca Invoke Operacje przychodzące z zewnątrz

32 Model orkiestracji diagram aktywności 2 Usługa sprzedaży Sprzedawca Zamówienie Klient PotwierdzenieZamówienia Receive Zamówienie Lokalne usługi sprzedawcy AnulowanieZamówienia SprawdźStanMagazynu Invoke SprawdźStanMagazynu Dostępność=True Dostępność=False Magazyn SprawdźMożliwośćDostawy Invoke SprawdźMożliwośćDostawy Dostawa=True Dostawa=False Send PotwierdźZamówienie Send AnulujZamówienie

33 Model orkiestracji diagram stanów (1) Rozszerzenie maszyny stanów Definicja aktywności na wejściu do/wyjściu z stanu Definicja aktywności wewnątrz stanu Obsługa zdarzeń Wykonanie aktywności Zmiana stanu Złożone przejścia (wiele aktywności) Równoległe stany Warunek wykonania aktywności [warunek]/start "aktywność" entry/start "aktywność" (wejście do stanu) do/start "aktywność" (operacja w stanie) exit/start "aktywność" (wyjście ze stanu)

34 Model orkiestracji diagram stanów (2) Uruchomiony /start "invoke SprawdźStanMagazynu" Wyszukiwanie produktów lokalnie Wyszukiwanie lokalne zakończone(namagazynie) [namagazynie=false]/start "invoke SprawdźDostępnośćUDostawcy Wyszukiwanie lokalne zakończone(namagazynie) [namagazynie=true]/start "send PotwerdzenieZamówienia" Wyszukiwanie produktów u dostawcy entry/start "invoke PodajNrUmowy" do/start "invoke CzyProduktDostepny" exit/start "invoke TerminDostawy" Wyszukiwanie u dostawcy zakończone(dostępność) [dostępność=false]/start "send AnulujZamówienie" Wyszukiwanie u dostawcy zakończone(dostępność) [dostępność=true]/start "send PotwierdzenieZamówienia" Zamówienie zakończone Zamówienie anulowane

35 Diagram aktywności vs diagram stanów Diagram aktywności Niejawna reprezentacja stanu Jawna reprezentacja aktywności Możliwość wyznaczenia aktualnie wykonywanej aktywności Diagram stanów Jawna reprezentacja stanu Jawna reprezentacja aktywności Aktywność przenosi system z jednego stanu spójnego do innego Nie ma możliwości zatrzymania się podczas wykonywania aktywności (atomowość) Możliwość wyznaczenia aktualnego stanu Nie można wyznaczyć aktualnie wykonywanej aktywności (założenie) Lepiej sprawdza się w złożonych systemach Diagram aktywności: zrozumienie wykonywanej aktywność wymaga kontekstu wykonania Diagram stanów: kontekst to stan!

36 Model orkiestracji Sieć Petriego (1) Połączenie Diagram aktywności Diagram stanów Dobrze znany formalizm Dobrze zdefiniowana semantyka bloczków Wiele narzędzi automatycznego przetwarzania Automatyczne wykrywanie właściwości model/przetwarzania Np.: wykrywanie zakleszczeń

37 Model orkiestracji Sieć Petriego (2) Graf miejsc i przejść Zbiór tokenów wskazuje na aktualny stan przetwarzania Przejście możliwe jeśli wszystkie miejsca wejściowe zawierają tokeny Z przejścia może wyjść dowolna liczba tokenów Jednorazowo można wykonać tylko jedno przejście Wydzielony miejsca Początkowy Końcowy

38 Model orkiestracji Sieć Petriego (3) Start (Wywołanie zamówienia) Wyszukiwanie produktów lokalnie Invoke SprawdzStanMagazynu namagazynie=false Invoke SprawdźDostępnośćUDostawcy namagazynie=true Wyszukiwanie produktów u dostawcy Dostępność=False Send AnulujZamówienie Zakończono (anulowano) Dostępność=True Gotowy do wysłania potwierdzenia Send PotwierdzenieZamówienia Zakończono (Potwierdzono)

39 Model orkiestracji rachunek π (1) Algebra procesów Połączenie Algebra of Communicating Processes with Abstractions (ACP) Calculus of Concurrent Systems (CCS) Możliwości uruchamiania aktywności Sekwencyjne A.B Aktywność A występuje przed B Równoległe A B Aktywność A występuje równolegle z B Warunkowe A+B Aktywność A lub aktywność B są uruchamiane Wybór niedeterministyczny [C1]A+[C2]B Aktywność A wykonywana pod warunkiem C1, B pod warunkiem C2

40 Model orkiestracji rachunek π (2) A = receivezamówienie.invokesprawdźstanmagazynu B = [namagazynie=false]c + [namagazynie=true]e C = invokesprawdźdostępnośćudostawcy.( [dostępność=false]sendanulujzamówienie + [dostępność=true]e ) E = sendpotwierdzzamówienie Zamówienie = A.B

41 Model orkiestracji hierarchia aktywności 1 Drzewo Zalety Podział złożonych aktywności Na aktywności składowe Liście = konkretne akcje Węzły pośrednie Porządek wykonania Wiele poziomów szczegółowości wykonania Naturalna modularyzacja

42 Model orkiestracji hierarchia aktywności 2 Przetwarzanie zamówienia sequence receive Zamówienie invoke SprawdźStanMagazynu Podejmij decyzję na podstawie stanu choice WyszukajUDostawcy sequence namagazynie=false namagazynie=true send PotwierdzenieZamówienia invoke SprawdzDostępnośćUDostawcy Podejmij decyzję na podstawie dostępności choice dostępność=false send AnulowanieZamówienie dostępność=true send PotwierdzenieZamówienia

43 Model regułowy orkiestracji (1) Zbiór reguł Reguła Część warunkowa Zdarzenie Warunek Część decyzyjna Akcja Paradygmat Event-Condition-Action (ECA) Reguły uruchamiane w wyniku wystąpienia zdarzenia Przychodzącego z zewnątrz W wyniku akcji reguł występują zdarzenia Uruchamiające warunki innych reguł

44 Model regułowy orkiestracji (2) Zalety Wady Łatwość modyfikacji Wysoka elastyczność Naturalny sposób obsługi wyjątków Trudno ustalić porządek wykonania Ale jest to możliwe Warunek w kolejnej regule musi uwzględniać stan po wykonaniu poprzedniej reguły Trudność zrozumienia i utrzymania dużego zbioru reguł

45 Model regułowy orkiestracji (3) ON receive Zamówienie IF True THEN invoke SprawdźStanMagazynu ON complete(sprawdźstanmagazynu) IF namagazynie == True THEN send PotwierdźZamówienie ON complete(sprawdźstanmagazynu) IF namagazynie == False THEN invoke SprawdźDostępnośćUDostawcy ON complete(sprawdźdostępnośćudostawcy) IF dostępny == True THEN send PotwierdzenieZamówienia ON complete(sprawdźdostępnoścudostawcy) IF dostępny == False THEN send AnulowanieZamówienia

46 Model danych i przepływu danych (1) Typy danych Dane aplikacyjne Wiadomości przesyłane między elementami systemu Dowolne typy i struktury danych Np.: Identyfikator produktu, wielkość zamówienia, cena Dane przepływu sterowania Zmienne procesu Użyte w instrukcjach warunkowych Zazwyczaj ograniczone do Boolean Number String Zazwyczaj uzyskane poprzez ekstrakcję z danych aplikacyjnych Np.: namagazynie, dostępność

47 Dwa podejścia do danych aplikacyjnych Black-box Dane identyfikowane przez URI Definicja niedostępna dla infrastruktury Infrastruktura nie wykorzystuje danych aplikacyjnych Infrastruktura przekazuje paczki danych między usługami Według definicji procesu Podejście jawne Dane przekazywane jawnie z/do usług Definicje struktur danych znane infrastrukturze Infrastruktura może wydzielić dane kontrolne

48 Black box vs podejście jawne Black box Model kompozycji niezależny od złożoności danych Owijacze dla usług Usługi oczekują danych, a nie identyfikatorów Przed uruchomieniem usługi należy pobrać dane wskazane przez URI Po wykonaniu usługi należy zmagazynować zwrócone dane pod określonym URI Podejście jawne Łatwość interpretacji odpowiedzi/statusu usługi Ryzyko przesyłania ogromnej ilości danych Operacje wykonywane na niewielkim fragmencie danych

49 Model przepływu danych Sposób przekazania danych z jednej operacji do innej Dwa podejścia Blackboard Dane użyte w usłudze złożonej Jawnie identyfikowane Dostępne na różnych etapach przetwarzania Kolekcja zmiennych Aktywności ustawiają i odczytują wartości Jawny model przepływu danych Przepływ między każdą parą aktywności modelowany osobno

50 Blackboard vs model jawny Blackboard Łatwość modelowania W dużej usłudze Konieczność organizacji danych w struktury Model zgodny z większością języków programowania Jawny model przepływu danych Elastyczność Lokalność Powoduje niejawne zależności w kolejności wykonania Np.: kiedy kolejność wykonania w modelu aktywności nie pokrywa się ze sposobem dostępu do danych (przykład ) Ryzyko wyścigu (ang. race condition) jeśli różne usługi składowe mogą dostarczyć te same dane

51 Niejawne zależności między usługami w modelu jawnego przepływu danych A B C Orkiestracja usług Przepływ danych

52 Selekcja usług (1) Sposób wyznaczenia usług składowych Gdzie wysyłać wiadomości Skąd pobierać dane Zwykle reprezentacja abstrakcyjna, np.: Identyfikator interfejsu Identyfikator roli usługi W czasie uruchomienia Abstrakcyjny opis jest wiązany z konkretnymi usługami

53 Selekcja usług (2) Wiązania usługi Statyczne URI usługi składowej zapisany w procesie Wygodne przy prototypowaniu i testowaniu Nieodporne na zmiany w środowisku Konieczna zmiana w definicji procesu Dynamiczne przez referencję URI usługi przechowywane przez zmienną procesu Źródło wartości Wywołanie innej usługi (np.: katalogu) URI klienta, który wywołał usługę (aby wywołać operacje u klienta) Wartość ustawiona podczas wdrożenia Jeśli wartość pobierana z katalogu Konieczność zamodelowania jako oddzielną aktywność

54 Selekcja usług (3) Dynamiczne przez wyszukiwanie Usługi składowe identyfikowane przez zbiór ograniczeń, np.: Wspierany interfejs konkretny tmodel z UDDI Konkretny dostawca businessentity w UDDI Infrastruktura automatycznie wyszukuje usługę Jeśli katalog zwróci wiele Wybór pierwszej Wybór losowej Dodatkowe kryterium wyboru

55 Porównanie sposobów selekcji usług Łatwość prototypowania i testowania Dostosowanie do zmian w środowisku Automatyzacja pobrania URI Statyczne Dynamiczne przez referencje Dynamiczne przez wyszukiwanie (wymagana infrastruktura, np.: katalog) (brak pobierania)

56 Selekcja usług (4) Dynamiczna selekcja operacji Wskazanie operacji usługi, którą wywołać Alternatywa dla modelowania wyboru usług przez orkiestrację Abstrakcyjne/generyczne aktywności Nazwa operacji w usłudze wybierana na podstawie przeszukiwania katalogu, np.: Wyszukiwanie operacji o semantyce wyspecyfikowanej w konkretnym tmodelu

57 Transakcje w kompozycji usług (1) Region atomowy Fragment schematu kompozycji Wykonanie wszystkich lub żadnej operacji z regionu Wobec braku możliwości wykonania operacji w regionie Wycofanie/kompensacja operacji wykonanych do tej pory Przerwanie wykonywania i zwrócenie błędu Obsługa po stronie infrastruktury Np.: użycie WS-Transaction

58 Transakcje w kompozycji usług (2) Jeśli usługi składowe nie obsługują WS-Transaction Możliwość obsługi na poziomie kompozycji BPEL Podział długich transakcji na podtransakcje Podtransakcje Wykonane w określonej kolejności Gwarancje ACID 2PC Powiązanie z podtransakcją kompensującą Rollback Przerwanie wszystkich aktywnych podtransakcji Kompensacja dla zatwierdzonych już podtransakcji W kolejności odwrotnej do pierwotnego wykonania

59 Transakcje w kompozycji usług (3) Akcja kompensująca przy braku wsparcia WS-Transaction Usługi jawnie nie dostarczają akcji kompensujących Utrudnia kompozycję usług Oddzielnego schemat orkiestracji dla kompensacji Wywołanie operacji kompensującej Np.: anulowanie wystawionego biletu Dla pewnych usług niemożliwe do wykonania Brak operacji kompensującej

60 Obsługa wyjątków w kompozycji (1) Wyjątek Odstępstwo od oczekiwanego wykonania kompozycji Sytuacje rzadkie i nietypowe Przykłady: Awaria usługi złożonej Awaria usługi składowej Wartość zwrócona przez usługę składową jest inna od oczekiwanej

61 Obsługa wyjątków w kompozycji Wyjątek Odstępstwo od oczekiwanego wykonania kompozycji Błąd, awaria Sytuacje rzadkie i nietypowe Przykłady: Błąd usługi złożonej Awaria usługi składowej Wartość zwrócona przez usługę składową jest inna od oczekiwanej

62 Obsługa wyjątków przez transakcje Wycofanie transakcji wobec wystąpienia wyjątku Przerost formy nad treścią Wiele wyjątków można obsłużyć bez kompensacji wykonanych aktywności Np.: Poprosić o poprawę danych

63 Podejście oparte o przepływ sterowania Wykorzystanie instrukcji warunkowych Sprawdzenie czy operacja powiodła się Uruchomienie odpowiedniej procedury obsługi Podobne do rozwiązań stosowanych w Językach bez obsługi wyjątków (np.: C) WinAPI Specyficzny przypadek: Problem stopu Komunikacja nieblokująca, usługa nie zwróciła żadnego wyjścia Komunikacja blokująca, usługa nie kończy przetwarzania Obsługa poprzez limit na czas uruchomienia i procedurę obsługi

64 Podejścia try-catch-throw Podobne do bloków try-catch w językach programowania Blok try Grupuje usługi pod jedną procedurą obsługi błędów Wyjątki rzucane dla nieoczekiwanych wartości zwracanych przez usługę Możliwość implementacji przez formę asercji Block catch Procedura obsługi błędów Możliwość rzucenia wyjątku dalej Do procedury obsługi na wyższym poziomie abstrakcji

65 Zalety try-catch-throw Separacja Logiki normalnego wykonania procesu Obsługi błędów Łatwość utrzymania W przypadku kompozycji hierarchicznej Możliwość zbudowania hierarchii wyjątków Od ogólnych do szczegółowych Strategia kontynuacji Definiuje, jak wykonywać usługę po wystąpieniu błędów

66 Podejście regułowe Dedykowane dla orkiestracji regułowej Użycie reguł Część warunkowa Zdarzenie Warunek wystąpienia wyjątku Np.: na danych zwracanych z usługi Część decyzyjna Procedura obsługi wyjątku

67 Zalety podejścia regułowego Separacja Logiki normalnego wykonania Obsługi błędów Dla dużej liczby reguł Działanie procesu staje się niezrozumiałe Trudność utrzymania

68 Związek koordynacji z kompozycją

69 Kompozycja vs koordynacja (1) Kompozycja Inaczej: implementacja usługi złożonej Implementacja prywatna Fakt kompozycji nie jest publikowany na zewnątrz Wykorzystanie innych usług Brak znajomości szczegółów operacyjnych usług Realizowana przez infrastrukturę Perspektywa klienta usługi Nie ma znaczenia, czy usługa jest prosta czy złożona

70 Kompozycja vs koordynacja (2) Koordynacja Publiczne dokumenty Umieszczane w katalogach usług Wynikają ze standaryzacji Interfejsów Opisu wspólnego wykonania usług Wsparcie dla Programisty tworzącego usługę Dynamicznego wiązania Wykonanie protokołu weryfikowane przez kontroler Kontroler = zaufana strona

71 Kompozycja vs koordynacja (3) Połączenie kompozycji z koordynacją Usługa A komponuje inne usługi B, C, w sobie znany sposób Każda z konwersacji A z B, A z C, B z C Jest koordynowana przez kontroler Usługi występujące w jednym protokole koordynacji będą koordynowane wspólnie Jedna usługa może brać udział w wielu protokołach koordynacji

72 Kompozycja vs koordynacja (4) Protokół koordynacji definiuje zachowanie Zewnętrzne Publicznie udokumentowane Schemat kompozycji definiuje realizację wewnętrzną Zachowania zewnętrznego i wewnętrznego Sposób realizacji jest prywatny

73 Transformacja między koordynacją i kompozycją Przejście od koordynacji do kompozycji Możliwe Zawężamy protokół do pojedynczej roli Przejście od kompozycji do koordynacji Niemożliwe Kompozycja zawiera perspektywę jednej roli w koordynacji Brakuje danych, aby zaprojektować model koordynacji wyłącznie na podstawie jeden kompozycji

74 Kompozycja usług na bazie protokołu koordynacji (1) Schemat kompozycji odpowiada funkcjonalności pojedynczej roli w koordynacji Aktywności wynikające z protokołu koordynacji Aktywności aplikacyjne Definicja protokołu koordynacji implikuje Ograniczenia na kompozycje usługi Np.: orkiestracja

75 Kompozycja usług na bazie protokołu koordynacji (2) Ogólna procedura: Ogranicz perspektywę protokołu do pojedynczej roli R R = rola komponowanej usługi złożonej Zdefiniuj szablon schematu kompozycji Uwzględniając aktywności protokołu Logika publiczna usługi Zdefiniuj logikę prywatną usługi

76 Kompozycja usług na bazie protokołu koordynacji (3) Operacje synchroniczne na roli R Request/Response aktywności Receive/Reply Orkiestracja musi zapewnić Wykonanie Reply po Receive Operacje synchroniczne inicjowane przez rolę R Request/Response aktywość Invoke

77 Kompozycja usług na bazie protokołu koordynacji (4) Operacje asynchroniczne pochodzące od innej roli Q Modelowane jako aktywność receive Operacje asynchroniczne pochodzące od roli R Modelowane jako aktywność send W BPEL invoke + odpowiednia deklaracja wiązania z usługą

78 Kompozycja usług na bazie protokołu koordynacji (5) Przenieś inne konstrukcje protokołu koordynacji Łuki Warunki Równoległe wykonanie Na aktywności, tak jak są dane

Wsparcie kompozycji i koordynacji w standardach 79 BPEL Nastawiony na kompozycje Modeluje proces Podział aktywności na Wewnętrzne Interakcję z innymi usługami ebxml Rozróżnienie Proces biznesowy Porozumienie biznesowe Forma protokołu interakcji Sposób interakcji indywidualnych procesów biznesowych Standard kładzie nacisk na modelowanie porozumienia biznesowego

80 Porównanie elementów infrastruktury Kontroler konwersacji Sprawdzenie zgodności wykonania z protokołem Trasowanie wiadomości do silnika kompozycji Silnik kompozycji Realizacja logiki usługi Transparentnie dla kontrolera konwersacji Wiązanie instancji kompozycji z instancją konwersacji Realizacja analogiczna do wiązania instancji usługi z konwersacją przez infrastrukturę Realizacja poprzez nagłówki SOAP

81 BPEL Web Services Business Process Execution Language

82 BPEL Formalnie WS-BPEL Powszechnie przyjęta nazwa BPEL Standard definicji procesu biznesowego Standard kompozycji usług Reprezentacja Diagram aktywności UML XML Ułatwia integracje usług Różnych dostawców Działających w różnych implementacjach Wykorzystujących standardy WS-*

83 Historia BPEL (1) 2001 rok Języki własnościowe Niepełne specyfikacje Przykłady Web Services Flow Langauge (IBM) Xlang (Microsoft) 2003 rok BPEL4WS v1.0 i v1.1 Połączenie rozwiązań IBM i Microsoft 2004 rok WS-BPEL 2.0 Zmiana nazwy Nowe aktywności: repeatuntil, validate, foreach, rethrow, extensionactivity, compensatescope

84 Historia BPEL (2) 2007 rok BPEL4People Aktywności realizowane przez ludzi jako komponenty w procesie biznesowym WS-HumanTask Opis specyfikacji zadań dla ludzi Właściwości Zachowania i operacje manipulujące właściwościami Specyfikacja niezależna od BPEL

85 Dwa paradygmaty kompozycji Orkiestracja Choreografia

86 Orkiestracja w BPEL Wyznaczona usługa centralna Realizuje proces biznesowy Odpowiednik centralnego zarządcy wykonania Pozostałe usługi Świadczą operacje na rzecz usługi centralnej Nie mają świadomości uczestnictwa w procesie biznesowym Źródło: Matjaz B. Juric, A Hands-on Introduction to BPEL, Oracle Corporation http://www.oracle.com/technetwork/articles/matjaz-bpel1-090575.html

87 Choreografia w BPEL Wiele usług wspólnie realizuje proces biznesowy Model kooperacyjny usługi świadome Roli w procesie Stanu wykonania procesu Operacje usług wykonane w odpowiednich krokach procesu Wiadomości koordynujące wykonanie Źródło: Matjaz B. Juric, A Hands-on Introduction to BPEL, Oracle Corporation http://www.oracle.com/technetwork/articles/matjaz-bpel1-090575.html

88 Zalety orkiestracji względem choreografii Zarządca wykonania jest znany Odpowiedzialność za wykonanie leży po jednej stronie Łatwość utrzymania Usługi mogą być wykorzystane bez modyfikacji Wystąpienie błędów Wykonanie alternatywnego scenariusza Usługa nie musi wiedzieć, że ma kompensować swój stan w wyniku awarii innej usługi

89 Zalety choreografii względem orkiestracji Rozproszone zarządzanie Bardziej odporne na awarię pojedynczych usług Ale: Wymaga odpowiednich procedur obsługi W mniejszych/rozwojowych systemach Zazwyczaj taka procedura nie jest zaimplementowana W dużych systemach Doświadczenie zebrane przy rozwoju sprawia, że takie procedury istnieją

90 Reprezentacje procesu biznesowego w BPEL Proces wykonywalny Ang. Executable Process Specyfikacja detali procesu Zgodne z paradygmatem orkiestracji Abstrakcyjny protokół biznesowy Ang. Abstract Business Protocol Specyfikacja wymiany publicznych wiadomości Brak wewnętrznych detali procesu Zgodne z paradygmatem choreografii

91 Główne elementy procesu biznesowego Aktywność Krok wykonania Deklaracje zmiennych <variable> Deklaracje powiązań usług <partnerlink>

92 Podział aktywności (1) Aktywności proste <invoke> Wywołanie innej usługi <receive> Oczekiwanie na wywołanie bieżącej usługi <reply> Utworzenie odpowiedzi na żądanie synchroniczne <assign> Przypisanie wartości do zmiennej <throw> Rzut wyjątkiem <wait> Oczekiwanie przez zadany czas <terminate> Zakończenie całego procesu

93 Podział aktywności (2) Aktywności ustrukturalizowane <sequence> Lista aktywności do wykonania <flow> Zbiór aktywności do równoległego wykonania <if> Warunkowe wykonanie <while>, <repeatuntil>, <foreach> Pętle <pick> Wybór jednej z wielu możliwych dróg wykonania

94 Przykładowy model w BPEL Źródło: Matjaz B. Juric, A Hands-on Introduction to BPEL, Oracle Corporation http://www.oracle.com/technetwork/articles/matjaz-bpel1-090575.html

95 Budowa procesu biznesowego <process name="businesstravelprocess" targetnamespace="http://packtpub.com/bpel/travel/" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:trv="http://packtpub.com/bpel/travel/" xmlns:emp="http://packtpub.com/service/employee/" xmlns:aln="http://packtpub.com/service/airline/" > <partnerlinks>  </partnerlinks> <variables>  </variables> <sequence>  </sequence> </process>

95 Budowa procesu biznesowego Podstawowa <process name="businesstravelprocess" targetnamespace="http://packtpub.com/bpel/travel/" przestrzeń nazw BPEL xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:trv="http://packtpub.com/bpel/travel/" xmlns:emp="http://packtpub.com/service/employee/" xmlns:aln="http://packtpub.com/service/airline/" > <partnerlinks>  </partnerlinks> <variables>  </variables> <sequence>  </sequence> </process>

96 <partnerlink> Wiązanie między usługami Zdefiniowane w WSDL Definicja interfejsu i sposobu dostępu Sposób na dynamiczne wiązanie XML (WSDL) pozwala na import Dokumentów Fragmentów dokumentów

97 <partnerlinktype> Definicja typu wiązania z usługą Dla synchronicznego interfejsu Jedna rola Wywołania w jedną stronę Dla asynchronicznego interfejsu Dwie role Jedna dla wywołania operacji przez klienta Druga dla wysłania odpowiedzi Callback

98 Deklaracja typu partnerlink procesu biznesowego z poprzedniego przykładu <plnk:partnerlinktype name="travellt" > <plnk:role name="travelservice"> <plnk:porttype name="tns:travelapprovalpt" /> </plnk:role> <plnk:role name="travelservicecustomer"> <plnk:porttype name="tns:clientcallbackpt" /> </plnk:role> </plnk:partnerlinktype>

98 Deklaracja typu partnerlink procesu biznesowego z poprzedniego przykładu <plnk:partnerlinktype name="travellt" > <plnk:role name="travelservice"> <plnk:porttype name="tns:travelapprovalpt" /> </plnk:role> <plnk:role name="travelservicecustomer"> <plnk:porttype name="tns:clientcallbackpt" /> </plnk:role> </plnk:partnerlinktype> Wskazanie na definicję WSDL Wskazanie na definicję WSDL

99 Deklaracja typu partnerlink dla pozostałych usług <plnk:partnerlinktype name="employeelt"> <plnk:role name="employeetravelstatusservice"> <plnk:porttype name="tns:employeetravelstatuspt" /> </plnk:role> </plnk:partnerlinktype> <plnk:partnerlinktype name="flightlt"> <plnk:role name="airlineservice"> <plnk:porttype name="tns:flightavailabilitypt" /> </plnk:role> <plnk:role name="airlinecustomer"> <plnk:porttype name="tns:flightcallbackpt" /> </plnk:role> </plnk:partnerlinktype>

100 Deklaracja konkretnych wiązań <partnerlink> <partnerlinks> <partnerlink name="client" partnerlinktype="trv:travellt" myrole="travelservice" partnerrole="travelservicecustomer"/> <partnerlink name="employeetravelstatus" partnerlinktype="emp:employeelt" partnerrole="employeetravelstatusservice"/> <partnerlink name="americanairlines" partnerlinktype="aln:flightlt" myrole="airlinecustomer" partnerrole="airlineservice"/> <partnerlink name="deltaairlines" partnerlinktype="aln:flightlt" myrole="airlinecustomer" partnerrole="airlineservice"/> </partnerlinks>

101 Zmienne w BPEL (1) Przechowywanie wiadomości Zwykle Transformacja wiadomości Zmiana formatu Jedna zmienna dla każdej wiadomości Wysłanej Odebranej

102 Zmienne w BPEL (2) <variables>  <variable name="travelrequest" messagetype="trv:travelrequestmessage"/>  <variable name="employeetravelstatusrequest" messagetype="emp:employeetravelstatusrequestmessage"/>  <variable name="employeetravelstatusresponse" messagetype="emp:employeetravelstatusresponsemessage"/>  <variable name="flightdetails" messagetype="aln:flightticketrequestmessage"/>  <variable name="flightresponseaa" messagetype="aln:travelresponsemessage"/>  <variable name="flightresponseda" messagetype="aln:travelresponsemessage"/>  <variable name="travelresponse" messagetype="aln:travelresponsemessage"/> </variables>

103 Główna część procesu (1) Zazwyczaj Rozpoczęcie od bloku <sequence> Możliwy inny sposób grupowania aktywności Np.: <pick> Dalej: odbiór wiadomości początkowej <receive>

104 Główna część procesu (2) <sequence>  <receive partnerlink="client" porttype="trv:travelapprovalpt" operation="travelapproval" variable="travelrequest" createinstance="yes" />  <assign> <copy> <from variable="travelrequest" part="employee"/> <to variable="employeetravelstatusrequest" part="employee"/> </copy> </assign>  <invoke partnerlink="employeetravelstatus" porttype="emp:employeetravelstatuspt" operation="employeetravelstatus" inputvariable="employeetravelstatusrequest" outputvariable="employeetravelstatusresponse" />  Rozproszone </sequence>

<assign> <copy> <from variable="travelrequest" part="flightdata"/> <to variable="flightdetails" part="flightdata"/> </copy> <copy> <from variable="employeetravelstatusresponse" part="travelclass"/> <to variable="flightdetails" part="travelclass"/> </copy> </assign> 105  <flow> <sequence>  <invoke partnerlink="americanairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="americanairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseaa" /> </sequence> <sequence>  <invoke partnerlink="deltaairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="deltaairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseda" /> </sequence> </flow>  Systemy Rozproszone

<if> <condition expressionlanguage="anyuri"> bpel:getvariableproperty('flightresponseda', '/confirmationdata/price')" > bpel:getvariableproperty('flightresponseaa', '/confirmationdata/price') </condition> <sequence>  <assign> <copy> <from variable="flightresponseaa" /> <to variable="travelresponse" /> </copy> </assign> </sequence> <else> <sequence>  <assign> <copy> <from variable="flightresponseda" /> <to variable="travelresponse" /> </copy> </assign> </sequence> </else> </if>  106

107 Główna część procesu (5)   <reply partnerlink="client" porttype="trv:clientcallbackpt" operation="clientcallback" inputvariable="travelresponse" />

108 Sygnalizowanie wyjątków Element <throw> Atrybut faultname typ wyjątku Atrybut faultvariable zawartość wyjątku Przykład: <sequence>  <assign> <copy> <from expression="string('credit card not approved')" /> <to variable="fault" part="error" /> </copy> </assign>  <throw faultname="buy:creditcardnotapproved" faultvariable="fault" /> </sequence>

109 Obsługa wyjątków (1) Definicja procedur obsługi wyjątków Ang. Handler Sekcja <faulthandlers> Dla każdego błędu oddzielny element <catch> Atrybut faultname typ błędu Atrybut faultvariable zawartość błędu Musi pasować typ zmiennej Musi wystąpić przynajmniej jeden z powyższych Element <catchall> Obsługa błędów nieobsłużonych przez pozostałe procedury

110 Obsługa wyjątków (2) Wyjątek rzucony bez powiązanej zmiennej (danych) Jeśli istnieje <catch> Z pasującym typem wyjątku Bez wyspecyfikowanej zmiennej To: uruchom procedurę w <catch> Jeśli istnieje <catchall> To: uruchom procedurę w <catchall> W przeciwnym wypadku zastosuj domyślną procedurę obsługi wyjątków Kompensacja Zatrzymanie procesu

111 Obsługa wyjątków (3) Wyjątek rzucony z powiązaną zmienną (dane) <catch> Z pasującym typem wyjątku Z pasującym typem zmiennej Jeśli dane wyjątku są wiadomością zdefiniowaną w WSDL Uruchom <catch>, dla którego nazwa wyjątku i nazwa zmiennej pokrywa się z faultname i faultelement we wiadomości <catch> Z pasującym typem wyjątku Bez wyspecyfikowanej zmiennej <catch> Bez typu wyjątku Z pasującym typem zmiennej Jeśli dane wyjątku są wiadomością zdefiniowaną w WSDL Nazwa wyjątku nie jest podana we wiadomości Uruchom <catch>, dla którego nazwa zmiennej pokrywa się z faultelement we wiadomości Jeśli istnieje <catchall> To: uruchom procedurę w <catchall> W przeciwnym wypadku zastosuj domyślną procedurę obsługi wyjątków

112 Obsługa wyjątków (3) <faulthandlers> <catch faultname="buy:creditcardnotapproved">  </catch> <catch faultname="buy:creditcardnotapproved" faultvariable="fault">  </catch> <catch faultvariable="fault">  </catch> <catchall>  </catchall> </faulthandlers>