Protokoły koordynacji usług

Protokoły koordynacji usług Tomasz Pawlak

2 Plan prezentacji Wprowadzenie Infrastruktura protokołów koordynacji WS-Coordination WS-Transaction WS-ReliableMessaging ebxml RosettaNet Pozostałe standardy

2 Plan prezentacji Wprowadzenie Infrastruktura protokołów koordynacji WS-Coordination WS-Transaction WS-ReliableMessaging ebxml RosettaNet Pozostałe standardy Za tydzień

3 Motywacja (1) SOAP, WSDL, UDDI wystarczają do Odnalezienia stron komunikacji Opisu sposobu przekazania informacji Przekazania informacji Wykonania operacji Prostych Pojedynczych Atomowych

4 Motywacja (2) Brakuje narzędzi Monitorowania wykonania Zarządzania wykonaniem Organizacji złożonych operacji Sekwencji powiązanych operacji Utrzymanie kontekstu wykonania (sesji) Uodpornienia na awarię Odtwarzania po awarii

4 Motywacja (2) Brakuje narzędzi Monitorowania wykonania Zarządzania wykonaniem Organizacji złożonych operacji Sekwencji powiązanych operacji Utrzymanie kontekstu wykonania (sesji) Uodpornienia na awarię Odtwarzania po awarii Funkcjonalność protokołów koordynacji usług

5 Protokół koordynacji usług Graf przepływu sterowania między usługami Specyfikuje ograniczenia na wykonanie operacji Ograniczenia kolejnościowe Równoległe przetwarzanie Dopuszczalne stany Konwersacja Instancja protokołu Pojęcie pokrewne: Proces workflow

6 Modelowanie konwersacji (1) Unified Modeling Language (UML) Język modelowania Różne aspekty systemów Nie tylko oprogramowanie Inżynieria systemów Procesy biznesowe Struktury organizacyjne Standard utrzymywany przez Object Management Group (OMG) Wersja 1.0: 1997 rok IBM, Microsoft, Oracle, HP Obecnie wersja 2.5 (2015 rok)

7 Modelowanie konwersacji (2) Maszyna stanów Dopuszczalne/poprawne stany Wyróżniony stan początkowy i końcowy Warunki i kierunki przejścia Jeden lub wiele dla każdego stanu Opisane przez trójki: <Klient, Operacja, Dostawca>

8 Modelowanie akcji Dlaczego trójka? <Klient, Operacja, Dostawca> Wiele usług może świadczyć tą samą operację Wielu klientów może wykonać tą samą operację Operacje dostępne warunkowo Tylko w pewnych stanach systemu Tylko dla pewnych klientów

9 Maszyna stanów przykład <K,ZapytanieOfertowe,S> Oferta przedstawiona Legenda: K Klient S Sprzedawca M Magazyn <K,Zamówienie,S> Zamówienie złożone <K,OdmowaPłatności,S> <K,Płatność,S> Zamówienie opłacone <S,ZlecenieRealizacji,M> Kompletowanie <S,Zwrot,K> Część środków do zwrotu Zamówienie anulowane <M,OdbiórTowaru,K> <M,BrakTowaru,K> <K,Akceptacja,M> <S,Zwrot,K> Zamówienie zrealizowane Oczekiwanie na reakcję klienta <K,Rezygnacja,M> Środki do zwrotu

10 Modelowanie konwersacji (3) Diagram sekwencji Role/aktorzy wydzieleni na pionowych osiach Przetwarzanie aktorów oznaczone na osi Interakcje między aktorami oznaczone przez strzałki

11 Diagram sekwencji przykład Klient Sprzedawca Klient Magazyn Klient Klient Sprzedawca Klient Magazyn Klient Klient Sprzedawca Klient Magazyn Klient ZapytanieOfertowe ZapytanieOfertowe ZapytanieOfertowe Zamówienie Zamówienie Zamówienie Płatność OdmowaPłatności Płatność OdbiórTowaru ZlecenieRealizacji BrakTowaru ZlecenieRealizacji alt Akceptacja Zwrot OdbiórTowaru Rezygnacja Zwrot

12 Maszyna stanów vs diagram sekwencji Maszyna stanów Główny element: stan systemu Niezmienny w czasie Statyczny Diagram sekwencji Główny element: akcja Element dynamiczny Zmienia stan systemu Dobre dla dużej liczby błędów/alternatyw Dla złożonych systemów Ogromna liczba stanów Trudno określić stan systemu Pojęcie pokrewne: Problem ustalenia spójnego obrazu stanu globalnego Dobre dla małej liczby alternatyw Stan reprezentowany niejawnie Akcja ograniczona przez wcześniejsze akcje Dla złożonych systemów Konieczność utworzenia wielu diagramów Sekwencyjne przetwarzanie Równoległe przetwarzanie

13 Modelowanie konwersacji (4) Diagram aktywności Inna forma diagramu sekwencji Wydzielone kolumny aktorów Kolejność akcji oznaczona strzałkami Alternatywy zagregowane na jednym diagramie

Diagram aktywności przykład 14 Realizacja zamówienia Klient Sprzedawca Magazyn ZapytanieOfertowe PrzygotowanieOferty Zamówienie Potwierdzenie zamówienia OdmowaPłatności Płatność ZlecenieRealizacji Kompletowanie BrakTowaru OdbiórTowaru Rezygnacja Akceptacja Zwrot AnulowanieZamówienia ZamówienieZrealizowane

15 Ukrycie informacji w protokole koordynacji Ukrycie zasad Podejmowania decyzji Wyboru ścieżek w grafie przetwarzania Zawężenie grafu przetwarzania Do perspektywy wymaganej dla określonej roli, np.: Perspektywa klienta nie zawiera roli magazynu Możliwe automatyczne ograniczenie przez narzędzia modelowania

16 Interfejs usługi vs protokół koordynacji Oba modelują dostępne operacje Opis interfejsu Formalny opis dostępnych metod i struktur Protokół koordynacji Semantyka Typowe/dopuszczalne użycie metod

17 Zastosowanie protokołu koordynacji Etap programowania Rozpoznanie dostępnych operacji Przykład wykorzystania usługi Generowanie szablonu usługi/klienta Etap pracy Dynamiczne wiązanie Wyszukiwanie usług pasujących do protokołu Dynamiczne zestawianie konwersacji przez infrastrukturę

18 Publikowanie protokołu koordynacji Katalog UDDI tmodel Zawiera protokół koordynacji Poszczególne perspektywy protokołu Wiele tmodeli bindingtemplate Wskazuje na tmodel Mówi, usługa implementuje protokół z tmodelu

19 Infrastruktura protokołów koordynacji

20 Kontroler konwersacji Ang. Conversation Controller Funkcjonalność Trasowanie Weryfikacja zgodności z protokołem

21 Trasowanie Przekazywanie wiadomości między obiektami Wiązanie żądań klienta z obiektami na serwerze usług Przynależność do konwersacji Przynależność do sesji Techniczna realizacja Identyfikator konwersacji w nagłówku wiadomości

22 Weryfikacja zgodności z protokołem Kontroler przetwarza każdą wiadomość Przerywa wykonanie, jeśli wiadomość nie pasuje do protokołu Wymagania: Protokół musi być zapisany w formalnym języku Np.: WS-Coordination

23 Procedura obsługi protokołu Ang. Handler Obsługuje wybrany protokół Np.: protokół koordynacji Zazwyczaj bez udziału/wywołania usługi

24 Sposoby uruchomienia handlera (1) Transparentnie dla usługi Handler Odbiera wiadomość Przetwarza Odsyła odpowiedź Brak wywołania usługi Przykład: WS-Reliability Infrastruktura zapewnia niezawodne dostarczenie wiadomości

25 Sposoby uruchomienia handlera (2) Współdzielony z usługą Handler zajmuje się koordynacją Usługa dostarcza procedury specyficzne dla aplikacji Np.: WS-Transaction Handler przetwarza komunikaty Początku transakcji Commit Rollback Usługa Zleca operacje transakcyjne Decyduje o zatwierdzeniu transakcji Dostarcza procedury komplementarne (w celu wycofania transakcji)

26 Zalety obsługi protokołów przez handler Odciążenie programisty usług Usługa może być nieświadoma innych stron konwersacji Infrastruktura decyduje o Przekazywaniu wiadomości Łączeniu stron konwersacji

27 Standaryzacja protokołów koordynacji Konieczna do współpracy infrastruktury różnych producentów Konieczne elementy standardu Sposób zapisu identyfikatorów konwersacji Np.: WS-Coordination, ebxml Zbiór meta-protokołów negocjacji protokołów Komunikacyjnych Koordynacji usług Standaryzacja protokołów komunikacji Aby osadzić identyfikatory we wiadomości Np.: SOAP Standardowy język zapisu protokołów Np.: XML

28 WS-Coordination

29 WS-Coordination Standard Baza dla innych protokołów koordynacji usług 2002 rok IBM Microsoft BEA Obecnie wersja 1.2 (2009 rok) Standard utrzymywany przez OASIS

30 Cele WS-Coordination Standaryzacja Przekazanie unikalnego identyfikatora między usługami Kontekst koordynacji Struktura danych Sposób umieszczenia w nagłówku SOAP Informowania handlera o adresie usługi biorącej udział w koordynacji Interfejs rejestracji Rejestracja handlerów przez usługi Informowania handlera o roli w konwersacji Interfejs aktywacji

31 Czym WS-Coordination nie jest? Konkretnym protokołem koordynacji Językiem specyfikacji protokołu koordynacji

32 Komponenty WS-Coordination Koordynatorzy Koordynują wykonanie usług Uczestnicy Zlecają koordynację własnych usług

33 Elementy opisu interakcji (1) Protokół koordynacji Zbiór reguł konwersacji pomiędzy koordynatorem, a uczestnikami Przykład: 2PC

34 Elementy opisu interakcji (2) Typ koordynacji Zbiór logicznie powiązanych protokołów koordynacji Przykład: Transakcja atomowa Grupa Dwufazowy commit (2PC) Powiadomienie (zdarzenie) o sposobie zakończenia transakcji Instancja typu koordynacji (konwersacja) Wywołanie wielu instancji protokołów Konkretny stan wykonania protokołu

35 Elementy opisu interakcji (3) Kontekst koordynacji Struktura danych Oznaczenie wiadomości należących do tej samej konwersacji Umieszczony w każdej wiadomości SOAP Zawartość Unikalny identyfikator konwersacji Dane protokołu koordynacji

36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11="http://www.w3.org/2003/05/soap-envelope"> <S11:Header>... <wscoor:coordinationcontext xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:myapp="http://www.example.com/myapp" S11:mustUnderstand="true"> <wscoor:identifier>http://fabrikam123.com/ss/1234</wscoor:identifier> <wscoor:expires>3000</wscoor:expires> <wscoor:coordinationtype>http://docs.oasis-open.org/ws-tx/wsat/2006/06</wscoor:coordinationtype> <wscoor:registrationservice> <wsa:address>http://business456.com/mycoordinationservice/registration</wsa:address> <wsa:referenceparameters> <myapp:betamark>... </myapp:betamark> <myapp:ebdcode>... </myapp:ebdcode> </wsa:referenceparameters> </wscoor:registrationservice> <myapp:isolationlevel>repeatableread</myapp:isolationlevel> </wscoor:coordinationcontext>... </S11:Header> </S11:Body>... </S11:Body > </S11:Envelope>

36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11="http://www.w3.org/2003/05/soap-envelope"> <S11:Header>... <wscoor:coordinationcontext xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:myapp="http://www.example.com/myapp" S11:mustUnderstand="true"> <wscoor:identifier>http://fabrikam123.com/ss/1234</wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Osadzenie we wiadomości SOAP <wscoor:coordinationtype>http://docs.oasis-open.org/ws-tx/wsat/2006/06</wscoor:coordinationtype> <wscoor:registrationservice> <wsa:address>http://business456.com/mycoordinationservice/registration</wsa:address> <wsa:referenceparameters> <myapp:betamark>... </myapp:betamark> <myapp:ebdcode>... </myapp:ebdcode> </wsa:referenceparameters> </wscoor:registrationservice> <myapp:isolationlevel>repeatableread</myapp:isolationlevel> </wscoor:coordinationcontext>... </S11:Header> </S11:Body>... </S11:Body > </S11:Envelope>

36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11="http://www.w3.org/2003/05/soap-envelope"> <S11:Header>... <wscoor:coordinationcontext xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:myapp="http://www.example.com/myapp" S11:mustUnderstand="true"> <wscoor:identifier>http://fabrikam123.com/ss/1234</wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination <wscoor:coordinationtype>http://docs.oasis-open.org/ws-tx/wsat/2006/06</wscoor:coordinationtype> <wscoor:registrationservice> <wsa:address>http://business456.com/mycoordinationservice/registration</wsa:address> <wsa:referenceparameters> <myapp:betamark>... </myapp:betamark> <myapp:ebdcode>... </myapp:ebdcode> </wsa:referenceparameters> </wscoor:registrationservice> <myapp:isolationlevel>repeatableread</myapp:isolationlevel> </wscoor:coordinationcontext>... </S11:Header> </S11:Body>... </S11:Body > </S11:Envelope>

36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11="http://www.w3.org/2003/05/soap-envelope"> <S11:Header>... <wscoor:coordinationcontext xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:myapp="http://www.example.com/myapp" S11:mustUnderstand="true"> <wscoor:identifier>http://fabrikam123.com/ss/1234</wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination Identyfikator konwersacji <wscoor:coordinationtype>http://docs.oasis-open.org/ws-tx/wsat/2006/06</wscoor:coordinationtype> <wscoor:registrationservice> <wsa:address>http://business456.com/mycoordinationservice/registration</wsa:address> <wsa:referenceparameters> <myapp:betamark>... </myapp:betamark> <myapp:ebdcode>... </myapp:ebdcode> </wsa:referenceparameters> </wscoor:registrationservice> <myapp:isolationlevel>repeatableread</myapp:isolationlevel> </wscoor:coordinationcontext>... </S11:Header> </S11:Body>... </S11:Body > </S11:Envelope>

36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11="http://www.w3.org/2003/05/soap-envelope"> <S11:Header>... <wscoor:coordinationcontext xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:myapp="http://www.example.com/myapp" S11:mustUnderstand="true"> <wscoor:identifier>http://fabrikam123.com/ss/1234</wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Typ koordynacji Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination Identyfikator konwersacji <wscoor:coordinationtype>http://docs.oasis-open.org/ws-tx/wsat/2006/06</wscoor:coordinationtype> <wscoor:registrationservice> <wsa:address>http://business456.com/mycoordinationservice/registration</wsa:address> <wsa:referenceparameters> <myapp:betamark>... </myapp:betamark> <myapp:ebdcode>... </myapp:ebdcode> </wsa:referenceparameters> </wscoor:registrationservice> <myapp:isolationlevel>repeatableread</myapp:isolationlevel> </wscoor:coordinationcontext>... </S11:Header> </S11:Body>... </S11:Body > </S11:Envelope>

36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11="http://www.w3.org/2003/05/soap-envelope"> <S11:Header>... <wscoor:coordinationcontext xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:myapp="http://www.example.com/myapp" S11:mustUnderstand="true"> <wscoor:identifier>http://fabrikam123.com/ss/1234</wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Typ koordynacji Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination Identyfikator konwersacji <wscoor:coordinationtype>http://docs.oasis-open.org/ws-tx/wsat/2006/06</wscoor:coordinationtype> <wscoor:registrationservice> <wsa:address>http://business456.com/mycoordinationservice/registration</wsa:address> <wsa:referenceparameters> <myapp:betamark>... </myapp:betamark> <myapp:ebdcode>... </myapp:ebdcode> </wsa:referenceparameters> </wscoor:registrationservice> <myapp:isolationlevel>repeatableread</myapp:isolationlevel> </wscoor:coordinationcontext>... </S11:Header> </S11:Body>... </S11:Body > </S11:Envelope> Dane protokołu koordynacji

37 Formy interakcji (1) Aktywacja Uczestnik żąda utworzenia kontekstu Występuje w każdym protokole koordynacji Np.: Rozpoczęcie transakcji atomowej Znaczenie Uczestnik otrzymuje nowy kontekst Koordynator poznaje swoją rolę w konwersacji Usługa może przekazać kontekst innego koordynatora Wtedy koordynator usługi staje się proxy

38 Przebieg aktywacji Usługa wysyła żądanie CreateCoordinationContext <CreateCoordinationContext> <Expires>... </Expires>? <CurrentContext>... </CurrentContext>? <CoordinationType>... </CoordinationType>... </CreateCoordinationContext> Koordynator odsyła CreateCoordinationContextResponse <CreateCoordinationContextResponse> <CoordinationContext> <Identifier>http://Business456.com/tm/context1234</Identifier> <CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06</CoordinationType> <RegistrationService> <wsa:address>http://business456.com/tm/registration</wsa:address> <wsa:referenceparameters> <myapp:privateinstance>1234</myapp:privateinstance> </wsa:referenceparameters> </RegistrationService> </CoordinationContext> </CreateCoordinationContextResponse>

38 Przebieg aktywacji Usługa wysyła żądanie CreateCoordinationContext <CreateCoordinationContext> <Expires>... </Expires>? <CurrentContext>... </CurrentContext>? <CoordinationType>... </CoordinationType>... </CreateCoordinationContext> Koordynator odsyła CreateCoordinationContextResponse <CreateCoordinationContextResponse> <CoordinationContext> <Identifier>http://Business456.com/tm/context1234</Identifier> <CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06</CoordinationType> <RegistrationService> <wsa:address>http://business456.com/tm/registration</wsa:address> <wsa:referenceparameters> <myapp:privateinstance>1234</myapp:privateinstance> </wsa:referenceparameters> </RegistrationService> </CoordinationContext> </CreateCoordinationContextResponse> Identyfikator

38 Przebieg aktywacji Usługa wysyła żądanie CreateCoordinationContext <CreateCoordinationContext> <Expires>... </Expires>? <CurrentContext>... </CurrentContext>? <CoordinationType>... </CoordinationType>... </CreateCoordinationContext> Koordynator odsyła CreateCoordinationContextResponse <CreateCoordinationContextResponse> <CoordinationContext> <Identifier>http://Business456.com/tm/context1234</Identifier> <CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06</CoordinationType> <RegistrationService> <wsa:address>http://business456.com/tm/registration</wsa:address> <wsa:referenceparameters> <myapp:privateinstance>1234</myapp:privateinstance> </wsa:referenceparameters> </RegistrationService> </CoordinationContext> </CreateCoordinationContextResponse> Identyfikator Adres usługi rejestracji

39 Formy interakcji (2) Rejestracja Uczestnik rejestruje się u koordynatora Deklaracja uczestnika do: Wzięcia udziału w protokole koordynacji Odbierania powiadomień o wykonanych krokach protokołu Wymiana informacji o interfejsach specyficznych dla protokołu Występuje w każdym protokole koordynacji

40 Rejestracja Usługa wysyła żądanie Register <Register> <ProtocolIdentifier>http://docs.oasis-open.org/ws-tx/wsat/2006/06/Volatile2PC</ProtocolIdentifier> <ParticipantProtocolService> <wsa:address>http://adventure456.com/participant2pcservice</wsa:address> <wsa:referenceparameters> <BetaMark>AlphaBetaGamma</BetaMark> </wsa:referenceparameters> </ParticipantProtocolService> </Register> Koordynator odpowiada RegisterResponse <RegisterResponse> <CoordinatorProtocolService> <wsa:address>http://business456.com/mycoordinationservice/coordinator</wsa:address> <wsa:referenceparameters> <myapp:markkey>%%f03ca2b%%</myapp:markkey> </wsa:referenceparameters> </CoordinatorProtocolService> </RegisterResponse>

40 Rejestracja Usługa wysyła żądanie Register <Register> <ProtocolIdentifier>http://docs.oasis-open.org/ws-tx/wsat/2006/06/Volatile2PC</ProtocolIdentifier> <ParticipantProtocolService> <wsa:address>http://adventure456.com/participant2pcservice</wsa:address> <wsa:referenceparameters> <BetaMark>AlphaBetaGamma</BetaMark> </wsa:referenceparameters> </ParticipantProtocolService> </Register> Koordynator odpowiada RegisterResponse <RegisterResponse> <CoordinatorProtocolService> <wsa:address>http://business456.com/mycoordinationservice/coordinator</wsa:address> <wsa:referenceparameters> <myapp:markkey>%%f03ca2b%%</myapp:markkey> </wsa:referenceparameters> </CoordinatorProtocolService> </RegisterResponse> Adres obsługi protokołu

40 Rejestracja Usługa wysyła żądanie Register <Register> <ProtocolIdentifier>http://docs.oasis-open.org/ws-tx/wsat/2006/06/Volatile2PC</ProtocolIdentifier> <ParticipantProtocolService> <wsa:address>http://adventure456.com/participant2pcservice</wsa:address> <wsa:referenceparameters> <BetaMark>AlphaBetaGamma</BetaMark> </wsa:referenceparameters> </ParticipantProtocolService> </Register> Koordynator odpowiada RegisterResponse <RegisterResponse> <CoordinatorProtocolService> <wsa:address>http://business456.com/mycoordinationservice/coordinator</wsa:address> <wsa:referenceparameters> <myapp:markkey>%%f03ca2b%%</myapp:markkey> </wsa:referenceparameters> </CoordinatorProtocolService> </RegisterResponse> Adres obsługi protokołu Adres obsługi protokołu

41 Formy interakcji (3) Interakcja specyficzna dla protokołu Opcjonalna Wymiana wiadomości zależnych od realizowane funkcjonalności Np.: Żądanie commit/rollback Potwierdzenie zatwierdzenia transakcji

42 Ogólny schemat interakcji Źródło: http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-os/wstx-wscoor-1.2-spec-os.html

43 Architektury koordynacji Zcentralizowana Rozproszona Jeden nadrzędny koordynator Każdy uczestnik korzysta z własnego koordynatora Usługa Usługa Usługa Usługa Usługa Usługa Koordynator Koordynator Koordynator Koordynator

44 Architektura mieszana Część usług posiada własnego koordynatora Istnieją koordynatorzy wykorzystywani wielokrotnie Usługa Usługa Usługa Koordynator Koordynator

Diagram sekwencji komunikacji zcentralizowana architektura 45 Infrastruktura Usługa A Logika usługi Koordynator aktywacji Koordynator C Koordynator rejestracji Koordynator protokołu Infrastruktura Usługa B Logika usługi Aktywuj kontekst koordnacji Kontekst koordynacji Rejestracja Adres koordynatora protokołu Wiadomość aplikacyjna Rejestracja Adres koordynatora protokołu Wiadomość specyficzna dla protokołu Wiadomość aplikacyjna Odpowiedź specyficzna dla protokołu Wiadomość aplikacyjna (odpowiedź) Wiadomość spec. protokołu

46 Diagram sekwencji komunikacji rozproszona architektura Usługa A Koordynator A Koordynator B Usługa B Aktywuj kontekst koordynacji Kontekst koordynacji Rejestracja Adres obsługi protokołu Wiadomość aplikacyjna Aktywuj kontekst koordynacji Kontekst koordynacji 2 Rejestracja Rejestracja Adres A obsługi protokołu Wiadomość protokołu Adres B obsługi protokołu Wiadomość protokołu Wiadomość protokołu Wiadomość aplikacyjna (odpowiedź) Wiadomość protokołu

47 Implementacja protokołu koordynacji bazującego na WS-Coordination Usługi negocjują koordynatora dla konwersacji Kontekst koordynacji Usługi mogą wybrać różnych koordynatorów Usługi rejestrują się w koordynatorach Koordynatorzy nawiązują połączenie ze sobą Wymiana wiadomości specyficznych dla protokołu Za pośrednictwem koordynatorów

48 Koordynacja usług we wcześniejszym middleware? Brak wydzielonego protokołu bazowego Dedykowane i różne protokoły Transakcji Niezawodnej komunikacji

49 Podobne rozwiązania CORBA Object Transaction Service (OTS) Zarządzanie operacjami transakcyjnymi na obiektach Główna różnica: CORBA OTS Pojedynczy koordynator wykonania Architektura scentralizowana WS-Coordination Wiele koordynatorów Architektura rozproszona Peer-to-peer

50 WS-Transaction

51 WS-Transaction Protokół transakcyjnego wykonania usług Zbudowany na bazie WS-Coordination Pierwsza wersja 2002 rok IBM Microsoft BEA Obecnie wersja 1.2 (2009 rok) Standard utrzymywany przez OASIS

52 Transakcje w usługach internetowych (1) Długi czas życia transakcji Zastosowanie w celach biznesowych Implikacje w świecie fizycznym Np.: Weryfikacja wykonania zamówienia Weryfikacja stanu magazynu może zająć wiele godzin Efekt: Nie można zagwarantować wszystkich właściwości ACID Wymagałoby to np.: Zakładania blokad na fizycznych zasobach Wycofania operacji wykonanych fizycznie (generujących koszty) Jak wycofać wysłany list?

53 Transakcje w usługach internetowych (2) Brak stałego zasobu Usługi mogą pracować na dowolnych zasobach Również na zasobach fizycznych Brak stałego modelu operacyjnego Usługi mogą realizować dowolne operacje Dla kontrastu W systemach zarządzania bazą danych Zasób: wiersz w tabeli Model operacyjny: Operacje CRUD na danych Commit Rollback

54 Rozluźnienie właściwości ACID Zapewnienie trwałości (Durability) Usługi wykorzystują trwały magazyn Po każdej akcji zapisują swój stan Stan widoczny poza transakcją Łamie gwarancje Atomowości Częściowe wyniki przetwarzania zmieniają stan systemu Izolacji Wyniki przetwarzania widoczne dla innych transakcji

55 Akcja kompensująca Wycofanie transakcji Usługa wykonuje akcję kompensującą wykonane dotąd (utrwalone) operacje Akcja kompensująca Specyficzna dla zastosowania Dostarczona przez usługę

56 Zastosowanie WS-Transaction Protokół informowania stron transakcji o Zmianie stanu transakcji Wystąpieniu błędu Zatwierdzeniu transakcji Wycofaniu transakcji WS-Transaction nie definiuje Akcji kompensujących Sposobu definiowania akcji kompensujących

57 WS-Transaction dwa standardy WS-AtomicTransaction Krótkie operacje Założenie: brak wpływu na stan fizyczny systemu Gwarancje ACID WS-BusinessActivity Długie operacje Przełożenie na operacje fizyczne Gwarancja trwałości (D)

58 Powiązanie z WS-Coordination WS-Coordination Uczestnik Koordynator Kontekst koordynacji Interfejs protokołu koordynacji WS-Transaction Usługa Zarządca transakcji Kontekst transakcji WSDL

59 WS-AtomicTransaction Standard definiuje protokoły koordynacji Completion 2 Phase Commit (2PC) Volatile 2PC Durable 2PC

60 Protokół Completion (1) Usługa inicjuje wykonanie Sygnalizacja chęci zatwierdzenia transakcji Sygnalizacja chęci wycofania transakcji Odbiorcą wiadomości jest koordynator W odpowiedzi rozpoczyna protokół 2PC Odpytuje inne usługi o zgodę na zatwierdzenie/wycofanie transakcji

61 Protokół Completion (2) Rollback Aborting Aborted Aborted Active Commit Completing Committed Ended Aborted Coordinator generated Initiator generated Źródło: OASIS, Web Services Atommic Transaction (WS-AtomicTransaction) Version 1.2, 2009

62 Protokół 2PC (1) 2 Phase Commit Protokół zakładania blokad na zasobach Dwie fazy Faza zakładania blokad (prepare) Przygotowanie zasobów do modyfikacji Faza zdejmowania blokad (commit) Podczas zatwierdzania transakcji Gwarantuje atomowość, izolację Może prowadzić do zakleszczenia! Zakończenie protokołu 2PC Przesłanie potwierdzenia zatwierdzenia transakcji do usług

63 Volatile vs Durable 2PC Volatile 2PC Dla zasobów ulotnych (np.: obiekt w pamięci) Możliwość rejestracji uczestników w trakcie fazy zakładania blokad Durable 2PC Dla zasobów trwałych (np.: krotka w bazie) Brak możliwości rejestracji uczestników w czasie wykonywania Faza zakładanie blokad Volatile przed Durable Zdejmowanie blokad W kolejności odwrotnej: Durable -> Volatile

64 Protokół 2PC (2) Rollback Aborting Aborted Active Prepare Prepared Commit Committed Preparing Prepared Committing Ended ReadOnly or Aborted ReadOnly or Aborted Coordinator generated Participant generated Źródło: OASIS, Web Services Atommic Transaction (WS-AtomicTransaction) Version 1.2, 2009

65 Typowy scenariusz wykonania Usługa A Koordynator A Koordynator B Usługa B Aktywacja kontekstu Kontekst Rejestracja "Completion" URI koordynatora "Completion" Operacja aplikacyjna Aktywacja kontekstu Kontekst Rejestracja "2PC" URI koordynatora A "2PC" Rejestracja "2PC" URI koordynatora B "2PC" Complete Prepare Prepare Prepared Commit Prepared Commit Committed Completed Committed

66 WS-BusinessActivity Długie transakcje Brak blokowania Dwa protokoły koordynacji BusinessAgreementWithParticipantCompletion BusinessAgreementWithCoordinatorCompletion

Protokół BusinessAgreementWithParticipantCompletion (1) 67 Informacja o statusie wykonania Exit usługa wychodzi z transakcji Zlecone zadania odrzucone Bieżące zadania anulowane Completed wykonane wszystkie zadania CannotComplete Usługa nie może wykonać powierzonych zadań Powodzenie w anulowaniu zadań Fail Usłudze nie udało się wykonać zadań Stan systemu jest nieokreślony Cancel Przerwanie transakcji przez kontroler W wyniku przerwania przez inną usługę

68 Protokół BusinessAgreementWithParticipantCompletion (2) Ustalenie konsensusu między usługami Kontynuowanie transakcji Kompensacja Przerwanie przetwarzania

Protokół BusinessAgreementWithParticipantCompletion (3) 69 Exit Exiting Exited Completed Close Closed Active Completed Closing Compensate Compensating Compensated Ended Fail Failing Failed Cancel Canceled Canceling Cannot Complete NotCompleting NotCompleted Coordinator generated Participant generated Źródło: OASIS, Web Services Business Activity (WS-BusinessActivity) Version 1.2, 2009

70 Protokół BusinessAgreementWithCoordinatorCompletion (1) Podobny do BusinessAgreementWithParticipantCompletion Usługa polega na zleceniach zadań przez koordynatora Koordynator informuje o zakończeniu zlecania zadań Status Complete

Protokół BusinessAgreementWithCoordinatorCompletion (2) 71 Exit Exiting Exited Complete Completed Close Closed Active Completing Completed Closing Ended Compensate Compensated Compensating Fail Failing Failed Cancel Canceling Canceled CannotComplete NotCompleting NotCompleted Coordinator generated Participant generated Źródło: OASIS, Web Services Business Activity (WS-BusinessActivity) Version 1.2, 2009

72 Typowy scenariusz wykonania Usługa A Koordynator A Koordynator B Usługa B Aktywacja kontekstu Kontekst Rejestracja "BusinessAgreement..." URI A "BusinessAgreement..." Operacja aplikacyjna Aktywacja kontekstu Kontekst Rejestracja "BusinessAgreement..." Rejestracja "BusinessAgreement..." URI A "BusinessAgreement..." URI B "BusinessAgreement..." Completed Fail Completed Compensate Compensate Compensated Compensated Failed

73 WS-ReliableMessaging

74 WS-ReliableMessaging Standard niezawodnego dostarczania wiadomości Zastąpił WS-Reliability (SOAP 1.1) Początek prac: 2003 rok IBM Microsoft BEA Tibco Obecnie wersja 1.2 (2009 rok) Standard utrzymywany przez OASIS

75 Założenia WS-ReliableMessaging Strony komunikacji Źródło aplikacyjne Ang. Application Source, AS Niezawodne źródło wiadomości Ang. Reliable Messaging Source, RMS Cel aplikacyjny Ang. Application Destination, AD Niezawodny cel wiadomości Ang. Reliable Messaging Destination, RMD Zawodna infrastruktura

75 Założenia WS-ReliableMessaging Strony komunikacji Źródło aplikacyjne Ang. Application Source, AS Niezawodne źródło wiadomości Ang. Reliable Messaging Source, RMS Cel aplikacyjny Ang. Application Destination, AD Niezawodny cel wiadomości Ang. Reliable Messaging Destination, RMD Zawodna infrastruktura Jeden proces lub oddzielne komponenty

75 Założenia WS-ReliableMessaging Strony komunikacji Źródło aplikacyjne Ang. Application Source, AS Niezawodne źródło wiadomości Ang. Reliable Messaging Source, RMS Cel aplikacyjny Ang. Application Destination, AD Niezawodny cel wiadomości Ang. Reliable Messaging Destination, RMD Zawodna infrastruktura Jeden proces lub oddzielne komponenty Jeden proces lub oddzielne komponenty

76 Zasada działania Potwierdzenia odebrania wiadomości Tylko na łączu RMS RMD Jedno potwierdzenie dla wielu wiadomości Trwałe kolejki wiadomości w RMS RMD Wiadomości grupowane w sesje Zapewnienie kolejności dostarczenia

77 Model komunikacji Źródło: WS-ReliableMessaging Wikipedia, the free encyclopedia, https://en.wikipedia.org/wiki/ws-reliablemessaging

78 Diagram aktywności Źródło aplikacyjne RMS RMD Cel aplikacyjny Wiadomość A Wiadomość A Wiadomość B Wiadomość B Limit czasu Wiadomość A Wiadomość A Wiadomość B Potwierdzenie A & B

79 Ograniczenia standardu WS-ReliableMessaging nie precyzuje Formatu wiadomości aplikacyjnych Formatu wiadomości i sposobu dostarczenia wiadomości AS RMS AD RMD

80 Obsługa błędów Jeśli RMS nie może dostarczyć wiadomości do RMD Niezależnie od powodu Np.: Jeśli retransmisje są nieskutecznie/niemożliwe RMS informuje AS przy użyciu wyjątku

81 Gwarancje dla wiadomości (1) AtLeastOnce Wiadomość dostarczona do AD co najmniej raz Mogą wystąpić duplikaty wiadomości! Raczej dla wiadomości wywołujących operacje idempotentne Różne wiadomości mogą dotrzeć w innej kolejności niż zostały wysłane Jeśli wiadomość nie może zostać dostarczona RMS rzuca wyjątkiem do AS Opcjonalnie: RMD rzuca wyjątkiem do AD Np.: Jeśli w ramach sesji brakuje jakiejś wiadomości

82 Gwarancje dla wiadomości (2) AtMostOnce Wiadomość zostanie dostarczona do AD co najwyżej raz Różne wiadomości mogą dotrzeć w innej kolejności niż zostały wysłane Wiadomość może nie zostać dostarczona Wystąpienie błędu nie jest raportowane do AS

83 Gwarancje dla wiadomości (3) ExactlyOnce Wiadomość zostanie dostarczona do AD dokładnie raz Różne wiadomości mogą dotrzeć w innej kolejności niż zostały wysłane Brak możliwości dostarczenia wiadomości RMS rzuca wyjątkiem do AS Opcjonalnie: RMD rzuca wyjątkiem do AD

84 Gwarancje dla wiadomości (4) InOrder Gwarancja FIFO dla komunikacji AS AD Brak gwarancji FIFO dla komunikacji RMS RMD Możliwość łączenia z dowolną gwarancją z wcześniejszych

85 Wsparcie infrastruktury Wykorzystanie WS-ReliableMessaging Parametr konfiguracyjny Np.: w WCF WSHttpBinding + ReliableSession WSDualHttpBinding = HttpTransport + TransactionFlow + ReliableSession + SymmetricSecurity +

86 ebxml

87 Electronic Business Using XML (ebxml) Standard ISO-15000 Wymiana informacji między przedsiębiorstwami Przygotowany przy współpracy UN/CEFACT ONZ Centrum Ułatwiania Handlu i Elektronicznego Biznesu OASIS Bazuje na Object-Oriented EDI

88 Elementy standardu ebxml Format wiadomości Zgodny z SOAP Komunikacja w stylu Dokument Protokół wymiany wiadomości Interoperacyjność Bezpieczeństwo Spójność Katalog usług Rejestracja usług Wyszukiwanie usług

89 Format wiadomości ebxml (1)

89 Format wiadomości ebxml (1) Dodatkowa warstwa abstrakcji nad kopertą SOAP! Podobne rozwiązanie do MTOM/XOP

90 Format wiadomości ebxml (2) eb:messageheader Wymagany Informacje o trasowaniu Kontekst wiadomości eb:error Błędy, które wystąpiły podczas wykonywania operacji eb:manifest Opcjonalny Opis danych wewnątrz wiadomości lub na zewnątrz (URL) Cel: aby łatwiej wyodrębnić dane z wiadomości

91 Protokoły koordynacji w ebxml (1) Collaboration Protocol Profile (CPP) Publikacja informacji przez partnerów biznesowych Obsługiwane procesy biznesowe Role stron w procesie biznesowym Dane kontaktowe Klasyfikacje przemysłowe Wymagania dot. interfejsów Wymagania dot. wymiany wiadomości Obsługa błędów

92 Protokoły koordynacji w ebxml (2) Collaboration Protocol Agreement (CPA) Protokół ustalania porozumienia biznesowego Zbudowane na bazie przecięcia kilku CPP Zawężanie CPP partnerów, aż ustalą swoje role Nadzorowanie wymiany wiadomości zgodnie z ustaleniami Katalog usług Partner A Partner B

92 Protokoły koordynacji w ebxml (2) Collaboration Protocol Agreement (CPA) Protokół ustalania porozumienia biznesowego Zbudowane na bazie przecięcia kilku CPP Zawężanie CPP partnerów, aż ustalą swoje role Nadzorowanie wymiany wiadomości zgodnie z ustaleniami Katalog usług CPP A Partner A Partner B

92 Protokoły koordynacji w ebxml (2) Collaboration Protocol Agreement (CPA) Protokół ustalania porozumienia biznesowego Zbudowane na bazie przecięcia kilku CPP Zawężanie CPP partnerów, aż ustalą swoje role Nadzorowanie wymiany wiadomości zgodnie z ustaleniami Katalog usług CPP A CPP B Partner A Partner B

92 Protokoły koordynacji w ebxml (2) Collaboration Protocol Agreement (CPA) Protokół ustalania porozumienia biznesowego Zbudowane na bazie przecięcia kilku CPP Zawężanie CPP partnerów, aż ustalą swoje role Nadzorowanie wymiany wiadomości zgodnie z ustaleniami Katalog usług CPP A CPA CPP B Partner A Partner B

93 ebxml vs usługi internetowe Funkcjonalnie ebxml = SOAP + WSDL + UDDI + MTOM + WS-Addressing + WS-Security + WS-ReliableMessaging + BPEL

94 Skąd wynika niska popularność ebxml?

94 Skąd wynika niska popularność ebxml? Złożony standard Duże koszty implementacji Trudno dostosować istniejące systemy

94 Skąd wynika niska popularność ebxml? Złożony standard Duże koszty implementacji Trudno dostosować istniejące systemy WS: Wiele prostych standardów Implementacja małymi krokami

94 Skąd wynika niska popularność ebxml? Złożony standard Duże koszty implementacji Trudno dostosować istniejące systemy WS: Wiele prostych standardów Implementacja małymi krokami Powiązana przyczyna: W pewnych zastosowaniach nie są wymagane pewne funkcjonalności Np.: transakcje System oparty o usługi internetowe może działać przy niepełnej implementacji standardów WS-*

95 Skąd wynika niska popularność ebxml? (2)

95 Skąd wynika niska popularność ebxml? (2) Usługi internetowe nastawione na integracje systemów

95 Skąd wynika niska popularność ebxml? (2) Usługi internetowe nastawione na integracje systemów ebxml nastawione na integrację procesów biznesowych Czy każdy system jest systemem biznesowym?

96 RosettaNet

97 RosettaNet Konsorcjum standaryzujące Protokoły e-commerce Ustanawianie partnerstwa biznesowego Zamawianie i dostawa towarów Wykorzystanie komunikacji internetowej 400 firm Producenci półprzewodników Producenci komponentów elektronicznych Producenci oprogramowania

98 Główne obszary standaryzacji (1) Procesy biznesowe RosettaNet Partner Interface Process (PIP) Protokół koordynacji wymiany towarów Specyfikacja dokumentów biznesowych Słownik pojęć Protokół specyfikacji zawartości wiadomości Publikowane w katalogu PIP

99 Główne obszary standaryzacji (2) Formaty danych RosettaNet Technical Dictionary Uniwersalny katalog produktów Nazwy Kody RosettaNet Business Dictionary Właściwości aktywności w procesach biznesowych Cel: Przezwyciężenie barier językowych

100 Główne obszary standaryzacji (3) Usługi wymiany wiadomości RosettaNet Implementation Framework (RNIF) Definiuje sposób wykonania procesu biznesowego (PIP) Wymiana wiadomości Bezpieczna Uwierzytelnienie Szyfrowanie Niezawodna Trasowanie wiadomości Format wiadomości

101 Partner Interface Process (PIP) Protokół koordynacji Oparty o współpracę stron Specyficzne dla PIP Słownik pojęć technicznych Komponenty wymieniane w komunikacji Wytyczne wymiany wiadomości Słownik pojęć biznesowych

102 Rodzaje wiadomości w PIP Akcja biznesowa Zawiera dokumenty biznesowe Np.: Zamówienie, rachunek Sygnał biznesowy Zawiera pozytywną lub negatywną odpowiedź na akcje biznesową

103 Krok 1 tworzenia specyfikacji PIP Przygotuj model istniejących procesów biznesowych Identyfikacja partnerów Wyznaczenie typów partnerów Odpowiedzialność, np.: Producent Dostawca Odbiorca

104 Krok 2 tworzenia specyfikacji PIP Wprowadź zmiany inżynieryjne w modelu Zmień sposób wymiany informacji Każda informacja przesłana innym medium niż Internet Np.: Telefon, poczta Powinna zostać przesłana przez Internet

105 Krok 3 tworzenia specyfikacji PIP Utwórz plan PIP (ang. blueprint) Wyspecyfikuj role partnerów Role organizacji Role konkretnych stanowisk Dla każdej roli określ jak zostaną spełnione jej cele biznesowe Procesy biznesowe zapisz w diagramie aktywności UML Wykonaj głosowanie nad planem Głosują członkowie RosettaNet

106 Krok 4 tworzenia specyfikacji PIP Utwórz protokół PIP Perspektywa operacyjna biznesu Warstwa akcji Opis interakcji biznesowych między partnerami Typy i role partnerów Słownik pojęć biznesowych Perspektywa funkcjonalna usługi Warstwa transakcji Opis wymiany wiadomości między usługami Np.: Sekwencja wiadomości do osiągnięcia celu biznesowego Protokoły koordynacji Informacje kontrolne dla akcji i sygnałów biznesowych Np.: czas na odesłanie sygnału po konkretnej akcji Perspektywa implementacji Warstwa usług Protokoły komunikacyjne Np.: Czy użyć szyfrowania TLS Format wiadomości Np.: XML Schema

107 Rodzaje PIP (1) PIP są klastrowane wg typów Klaster 0: Wsparcie RosettaNet Akcje administracyjne Np.: Powiadomienie o awarii Test asynchronicznych powiadomień

108 Rodzaje PIP (2) Klaster 1: Przegląd produktów i usług partnera Sposób zarządzania informacją o produktach i usługach Zbieranie Utrzymywanie Rozprowadzanie Np.: Tworzenie konta w systemie Subskrybowanie zmian cen produktów

109 Rodzaje PIP (3) Klaster 2: Informacje o produkcie Dystrybucja Uaktualnienie Np.: Pobranie informacji technicznych o produkcie

110 Rodzaje PIP (4) Klaster 3: Zarządzanie zamówieniami Np.: Zapytanie ofertowe Pobranie statusu zamówienia Klaster 4: Zarządzanie magazynem Np.: Utworzenie raportu o stanie magazynu Wydanie towaru z magazynu

111 Rodzaje PIP (5) Klaster 5: Zarządzanie informacjami marketingowymi Wsparcie dla wymiany informacji marketingowych Np.: Rozesłanie listy produktów Reklamowanie produktów

112 Rodzaje PIP (6) Klaster 6: Wsparcie Wsparcie techniczne Obsługa gwarancji, rękojmi Naprawy Np.: Zgłoszenie reklamacji

113 Rodzaje PIP (7) Klaster 7: Wytwarzanie Wsparcie dla wirtualnego wytwarzania Np.: Powiadomienia o kolejności prac podczas produkcji Dystrybucja informacji o jakości produktów

RosettaNet Implementation Framework (RNIF) (1) 114 Definicja protokołów implementujących standardy PIP Format wiadomości Format nagłówka Informacje kontekstowe Sposób zapisu akcji i sygnałów biznesowych Wiązania protokołów Synchroniczna i asynchroniczna komunikacja Stos protokołów Niezawodna komunikacja HTTP i SMTP jako protokoły transportowe

115 RosettaNet Implementation Framework (RNIF) (2) Mechanizmy bezpieczeństwa Podpis cyfrowy Szyfrowanie wiadomości Uwierzytelnienie Autoryzacja Niezaprzeczalność Dostarczanie dowodów, że określona wiadomość Została nadana Została odebrana

116 Format wiadomości Źródło: http://docs.oracle.com/cd/e13160_01/wli/docs10gr3/tpintro/rosettanet.html

117 Powiązane standardy

118 XML Common Business Library (xcbl) Standard wymiany dokumentów biznesowych Główny obszar zainteresowań E-Commerce Nabycie i handel towarami V1.0: 1997 rok Commerce One Inc. Obecnie v4.0 (2003 rok) Standard utrzymywany przez Perfect Commerce Inc.

119 xcbl 4.0 XMLowy odpowiednik wiadomości EDIFACT Definicja 44 formatów dokumentów 8 kategorii Dla każdego określone Przypadek użycia Warunki użycia (ograniczenia) Zawartość Semantyka zawartości Role stron Wyróżnienie strony inicjującej

120 Web Service Choreography Interface (WSCI) Język definiowania protokołów koordynacji Wysokopoziomowy Nie precyzuje aspektów implementacyjnych Rozszerzenie WSDL V1.0: 2002 rok SAP BEA Sun

121 Cechy WSCI Dodaje ograniczenia kolejnościowe dla operacji w WSDL Jeden dokument WSCI Jeden protokół koordynacji Wiele dokumentów WSCI Może referować jeden dokument WSDL Odpowiednik wielu przypadków użycia

122 Model protokołu w WSCI Zasadniczo odpowiednik diagramu aktywności Dodatkowo: Obsługa błędów Sekwencja akcji do wykonania w razie wystąpienia błędu Transakcje Grupowanie akcji w atomowe operacje Wskazywanie akcji kompensujących Korelacje Łączenie wiadomości w konwersacje Wskazanie porcji danych we wiadomości jako identyfikatorów Ograniczenia czasowe Definiowanie ograniczeń na czas wykonania operacje Wskazanie procedur obsługi w razie przekroczenia czasu

123 Przykład modelu Źródło: W3C, Web Service Choreography Interface (WSCI) 1.0 http://www.w3.org/tr/wsci/

Przykład interfejsu z ograniczeniami z modelu <wsdl:definitions name="airline" targetnamespace="http://example.com/consumer/airline" xmlns="http://www.w3.org/2002/07/wsci10" xmlns:defs="http://example.com/consumer/definitions" xmlns:tns="http://example.com/consumer/airline" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:import namespace="http://example.com/consumer/definitions" location="http://example.com/messages.wsdl" /> <wsdl:import namespace="http://example.com/consumer/definitions" location="http://example.com/definitions.wsci" /> <!-- *************AIRLINE INTERFACE ******************************* --> <interface name="airline"> <documentation> The interface models the behavior of the Airline service with Respect to all of the other parties involved in the overall process. </documentation> <process name="verifyseats" instantiation="message"> <action name="verifyseatavailability" role="tns:airline" operation="tns:airlinetota/verifyseatavailability"/> </process> <process name="planandbooktrip" instantiation="message" > <sequence> <context> <transaction name="seatreservation" type="atomic"> <compensation> <action name="notifyofcancellation" role="tns:airline" operation="tns:airlinetota/notifyofcancellation"/> </compensation> </transaction> </context> <action name="reserveseat" role="tns:airline" operation="tns:airlinetota/reserveseat"/> <while name="reserveseats"> <condition>defs:notlastseat</condition> <action name="reservenextseat" role="tns:airline" operation="tns:airlinetota/reserveseat"> <correlate correlation="defs:reservationcorrelation" /> </action> </while> </sequence> <sequence> <context> <exception> <ontimeout property="tns:expirytime" type="duration" reference="tns:reserveseats@end"> <compensate name="compensatereservation" transaction="seatreservation"/> </ontimeout> </exception> </context> <choice> <onmessage> <action name="receivecancellationrequest" role="tns:airline" operation="tns:airlinetota/cancelreservation"> <correlate correlation="defs:reservationcorrelation"/> </action> <compensate name="compensatereservation" transaction="seatreservation"/> </onmessage> 124 <onmessage> <action name="performbooking" role="tns:airline" operation="tns:airlinetota/bookseats"> <correlate correlation="defs:reservationcorrelation"/> </action>

125 Dziękuję za uwagę Proszę o pytania