Kompozycja usług. Tomasz Pawlak. Biznesowe Systemy Rozproszone

Transkrypt

1 Kompozycja usług Tomasz Pawlak

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

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

4 3 Czym jest kompozycja usług?

5 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

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

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

8 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

9 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

10 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

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

12 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

13 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

14 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

15 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

16 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

17 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

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

19 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)

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

21 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

22 12 Kompozycja usług dawniej i dziś

23 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

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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 22 Modele kompozycji usług

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

34 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

35 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

36 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

37 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

38 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

39 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

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

41 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

42 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

43 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)

44 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

45 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!

46 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ń

47 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

48 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)

49 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

50 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

51 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

52 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

53 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ł

54 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ł

55 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

56 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ść

57 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

58 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

59 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

60 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

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

62 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

63 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ść

64 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

65 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)

66 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

67 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

68 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

69 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

70 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

71 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

72 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

73 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

74 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

75 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

76 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

77 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

78 68 Związek koordynacji z kompozycją

79 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

80 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

81 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

82 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

83 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

84 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

85 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

86 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

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

88 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

89 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

90 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

91 81 BPEL Web Services Business Process Execution Language

92 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-*

93 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

94 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

95 85 Dwa paradygmaty kompozycji Orkiestracja Choreografia

96 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

97 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

98 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

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

100 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

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

102 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

103 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

104 94 Przykładowy model w BPEL Źródło: Matjaz B. Juric, A Hands-on Introduction to BPEL, Oracle Corporation

105 95 Budowa procesu biznesowego <process name="businesstravelprocess" targetnamespace=" xmlns=" xmlns:trv=" xmlns:emp=" xmlns:aln=" > <partnerlinks> <!-- Deklaracje wiązań usług --> </partnerlinks> <variables> <!-- Deklaracje zmiennych --> </variables> <sequence> <!-- Główna część procesu biznesowego, Start następuje po żądaniu z zewnątrz. --> </sequence> </process>

106 95 Budowa procesu biznesowego Podstawowa <process name="businesstravelprocess" targetnamespace=" przestrzeń nazw BPEL xmlns=" xmlns:trv=" xmlns:emp=" xmlns:aln=" > <partnerlinks> <!-- Deklaracje wiązań usług --> </partnerlinks> <variables> <!-- Deklaracje zmiennych --> </variables> <sequence> <!-- Główna część procesu biznesowego, Start następuje po żądaniu z zewnątrz. --> </sequence> </process>

107 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

108 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

109 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>

110 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>

111 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

112 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>

113 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>

114 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>

115 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>

116 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>

117 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>

118 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>

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

120 102 Zmienne w BPEL (2) <variables> <!-- input for this process --> <variable name="travelrequest" messagetype="trv:travelrequestmessage"/> <!-- input for the Employee Travel Status Web service --> <variable name="employeetravelstatusrequest" messagetype="emp:employeetravelstatusrequestmessage"/> <!-- output from the Employee Travel Status Web service --> <variable name="employeetravelstatusresponse" messagetype="emp:employeetravelstatusresponsemessage"/> <!-- input for American and Delta Web services --> <variable name="flightdetails" messagetype="aln:flightticketrequestmessage"/> <!-- output from American Airlines --> <variable name="flightresponseaa" messagetype="aln:travelresponsemessage"/> <!-- output from Delta Airlines --> <variable name="flightresponseda" messagetype="aln:travelresponsemessage"/> <!-- output from BPEL process --> <variable name="travelresponse" messagetype="aln:travelresponsemessage"/> </variables>

121 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>

122 104 Główna część procesu (2) <sequence> <!-- Receive the initial request for business travel from client --> <receive partnerlink="client" porttype="trv:travelapprovalpt" operation="travelapproval" variable="travelrequest" createinstance="yes" /> <!-- Prepare the input for the Employee Travel Status Web Service --> <assign> <copy> <from variable="travelrequest" part="employee"/> <to variable="employeetravelstatusrequest" part="employee"/> </copy> </assign> <!-- Synchronously invoke the Employee Travel Status Web Service --> <invoke partnerlink="employeetravelstatus" porttype="emp:employeetravelstatuspt" operation="employeetravelstatus" inputvariable="employeetravelstatusrequest" outputvariable="employeetravelstatusresponse" /> <!-- Biznesowe... Systemy --> Rozproszone </sequence>

123 104 Główna część procesu (2) <sequence> <!-- Receive the initial request for business travel from client --> <receive partnerlink="client" porttype="trv:travelapprovalpt" operation="travelapproval" variable="travelrequest" createinstance="yes" /> <!-- Prepare the input for the Employee Travel Status Web Service --> <assign> <copy> <from variable="travelrequest" part="employee"/> <to variable="employeetravelstatusrequest" part="employee"/> </copy> </assign> <!-- Synchronously invoke the Employee Travel Status Web Service --> <invoke partnerlink="employeetravelstatus" porttype="emp:employeetravelstatuspt" operation="employeetravelstatus" inputvariable="employeetravelstatusrequest" outputvariable="employeetravelstatusresponse" /> <!-- Biznesowe... Systemy --> Rozproszone </sequence>

124 104 Główna część procesu (2) <sequence> <!-- Receive the initial request for business travel from client --> <receive partnerlink="client" porttype="trv:travelapprovalpt" operation="travelapproval" variable="travelrequest" createinstance="yes" /> <!-- Prepare the input for the Employee Travel Status Web Service --> <assign> <copy> <from variable="travelrequest" part="employee"/> <to variable="employeetravelstatusrequest" part="employee"/> </copy> </assign> <!-- Synchronously invoke the Employee Travel Status Web Service --> <invoke partnerlink="employeetravelstatus" porttype="emp:employeetravelstatuspt" operation="employeetravelstatus" inputvariable="employeetravelstatusrequest" outputvariable="employeetravelstatusresponse" /> <!-- Biznesowe... Systemy --> Rozproszone </sequence>

125 <! > <!-- Prepare the input for AA and DA --> <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 <!-- Make a concurrent invocation to AA in DA --> <flow> <sequence> <!-- Async invoke of the AA Web service and wait for the callback--> <invoke partnerlink="americanairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="americanairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseaa" /> </sequence> <sequence> <!-- Async invoke of the DA Web service and wait for the callback--> <invoke partnerlink="deltaairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="deltaairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseda" /> </sequence> </flow> <!-- Biznesowe... --> Systemy Rozproszone

126 <! > <!-- Prepare the input for AA and DA --> <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 <!-- Make a concurrent invocation to AA in DA --> <flow> <sequence> <!-- Async invoke of the AA Web service and wait for the callback--> <invoke partnerlink="americanairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="americanairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseaa" /> </sequence> <sequence> <!-- Async invoke of the DA Web service and wait for the callback--> <invoke partnerlink="deltaairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="deltaairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseda" /> </sequence> </flow> <!-- Biznesowe... --> Systemy Rozproszone

127 <! > <!-- Prepare the input for AA and DA --> <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 <!-- Make a concurrent invocation to AA in DA --> <flow> <sequence> <!-- Async invoke of the AA Web service and wait for the callback--> <invoke partnerlink="americanairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="americanairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseaa" /> </sequence> <sequence> <!-- Async invoke of the DA Web service and wait for the callback--> <invoke partnerlink="deltaairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="deltaairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseda" /> </sequence> </flow> <!-- Biznesowe... --> Systemy Rozproszone

128 <! > <!-- Prepare the input for AA and DA --> <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 <!-- Make a concurrent invocation to AA in DA --> <flow> <sequence> <!-- Async invoke of the AA Web service and wait for the callback--> <invoke partnerlink="americanairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="americanairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseaa" /> </sequence> <sequence> <!-- Async invoke of the DA Web service and wait for the callback--> <invoke partnerlink="deltaairlines" porttype="aln:flightavailabilitypt" operation="flightavailability" inputvariable="flightdetails" /> <receive partnerlink="deltaairlines" porttype="aln:flightcallbackpt" operation="flightticketcallback" variable="flightresponseda" /> </sequence> </flow> <!-- Biznesowe... --> Systemy Rozproszone

129 <! > <!-- Select the best offer and construct the TravelResponse --> <if> <condition expressionlanguage="anyuri"> bpel:getvariableproperty('flightresponseda', '/confirmationdata/price')" > bpel:getvariableproperty('flightresponseaa', '/confirmationdata/price') </condition> <sequence> <!-- Select American Airlines --> <assign> <copy> <from variable="flightresponseaa" /> <to variable="travelresponse" /> </copy> </assign> </sequence> <else> <sequence> <!-- Select Delta Airlines --> <assign> <copy> <from variable="flightresponseda" /> <to variable="travelresponse" /> </copy> </assign> </sequence> </else> </if> <! > 106

130 <! > <!-- Select the best offer and construct the TravelResponse --> <if> <condition expressionlanguage="anyuri"> bpel:getvariableproperty('flightresponseda', '/confirmationdata/price')" > bpel:getvariableproperty('flightresponseaa', '/confirmationdata/price') </condition> <sequence> <!-- Select American Airlines --> <assign> <copy> <from variable="flightresponseaa" /> <to variable="travelresponse" /> </copy> </assign> </sequence> <else> <sequence> <!-- Select Delta Airlines --> <assign> <copy> <from variable="flightresponseda" /> <to variable="travelresponse" /> </copy> </assign> </sequence> </else> </if> <! > 106

131 <! > <!-- Select the best offer and construct the TravelResponse --> <if> <condition expressionlanguage="anyuri"> bpel:getvariableproperty('flightresponseda', '/confirmationdata/price')" > bpel:getvariableproperty('flightresponseaa', '/confirmationdata/price') </condition> <sequence> <!-- Select American Airlines --> <assign> <copy> <from variable="flightresponseaa" /> <to variable="travelresponse" /> </copy> </assign> </sequence> <else> <sequence> <!-- Select Delta Airlines --> <assign> <copy> <from variable="flightresponseda" /> <to variable="travelresponse" /> </copy> </assign> </sequence> </else> </if> <! > 106

132 <! > <!-- Select the best offer and construct the TravelResponse --> <if> <condition expressionlanguage="anyuri"> bpel:getvariableproperty('flightresponseda', '/confirmationdata/price')" > bpel:getvariableproperty('flightresponseaa', '/confirmationdata/price') </condition> <sequence> <!-- Select American Airlines --> <assign> <copy> <from variable="flightresponseaa" /> <to variable="travelresponse" /> </copy> </assign> </sequence> <else> <sequence> <!-- Select Delta Airlines --> <assign> <copy> <from variable="flightresponseda" /> <to variable="travelresponse" /> </copy> </assign> </sequence> </else> </if> <! > 106

133 107 Główna część procesu (5) <! > <!-- Make a callback to the client --> <reply partnerlink="client" porttype="trv:clientcallbackpt" operation="clientcallback" inputvariable="travelresponse" />

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

135 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

136 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

137 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

138 112 Obsługa wyjątków (3) <faulthandlers> <catch faultname="buy:creditcardnotapproved"> <!-- Dopasowanie wg typu błędu, wartość zmiennej niedostępna w środku --> </catch> <catch faultname="buy:creditcardnotapproved" faultvariable="fault"> <!-- Dopasowanie wg typu błędu i typu zmiennej zawierającej opis błędu --> </catch> <catch faultvariable="fault"> <!-- Dopasowanie wg typu zmiennej zawierającej opis błędu --> </catch> <catchall> <!-- Obsługa wszystkich wcześniej nieobsłużonych błędów --> </catchall> </faulthandlers>