Protokoły koordynacji usług

Transkrypt

1 Protokoły koordynacji usług Tomasz Pawlak

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

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

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

5 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

6 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

7 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

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

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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

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

20 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

21 19 Infrastruktura protokołów koordynacji

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

23 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

24 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

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

26 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

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

28 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

29 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

30 28 WS-Coordination

31 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

32 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

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

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

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

36 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

37 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

38 36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11=" <S11:Header>... <wscoor:coordinationcontext xmlns:wsa=" xmlns:wscoor=" xmlns:myapp=" S11:mustUnderstand="true"> <wscoor:identifier> <wscoor:expires>3000</wscoor:expires> <wscoor:coordinationtype> <wscoor:registrationservice> <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>

39 36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11=" <S11:Header>... <wscoor:coordinationcontext xmlns:wsa=" xmlns:wscoor=" xmlns:myapp=" S11:mustUnderstand="true"> <wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Osadzenie we wiadomości SOAP <wscoor:coordinationtype> <wscoor:registrationservice> <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>

40 36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11=" <S11:Header>... <wscoor:coordinationcontext xmlns:wsa=" xmlns:wscoor=" xmlns:myapp=" S11:mustUnderstand="true"> <wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination <wscoor:coordinationtype> <wscoor:registrationservice> <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>

41 36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11=" <S11:Header>... <wscoor:coordinationcontext xmlns:wsa=" xmlns:wscoor=" xmlns:myapp=" S11:mustUnderstand="true"> <wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination Identyfikator konwersacji <wscoor:coordinationtype> <wscoor:registrationservice> <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>

42 36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11=" <S11:Header>... <wscoor:coordinationcontext xmlns:wsa=" xmlns:wscoor=" xmlns:myapp=" S11:mustUnderstand="true"> <wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Typ koordynacji Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination Identyfikator konwersacji <wscoor:coordinationtype> <wscoor:registrationservice> <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>

43 36 Kontekst koordynacji przykład <S11:Envelope xmlns:s11=" <S11:Header>... <wscoor:coordinationcontext xmlns:wsa=" xmlns:wscoor=" xmlns:myapp=" S11:mustUnderstand="true"> <wscoor:identifier> <wscoor:expires>3000</wscoor:expires> Typ koordynacji Osadzenie we wiadomości SOAP Przestrzeń nazw WS-Coordination Identyfikator konwersacji <wscoor:coordinationtype> <wscoor:registrationservice> <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

44 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

45 38 Przebieg aktywacji Usługa wysyła żądanie CreateCoordinationContext <CreateCoordinationContext> <Expires>... </Expires>? <CurrentContext>... </CurrentContext>? <CoordinationType>... </CoordinationType>... </CreateCoordinationContext> Koordynator odsyła CreateCoordinationContextResponse <CreateCoordinationContextResponse> <CoordinationContext> <Identifier> <CoordinationType> <RegistrationService> <wsa:address> <wsa:referenceparameters> <myapp:privateinstance>1234</myapp:privateinstance> </wsa:referenceparameters> </RegistrationService> </CoordinationContext> </CreateCoordinationContextResponse>

46 38 Przebieg aktywacji Usługa wysyła żądanie CreateCoordinationContext <CreateCoordinationContext> <Expires>... </Expires>? <CurrentContext>... </CurrentContext>? <CoordinationType>... </CoordinationType>... </CreateCoordinationContext> Koordynator odsyła CreateCoordinationContextResponse <CreateCoordinationContextResponse> <CoordinationContext> <Identifier> <CoordinationType> <RegistrationService> <wsa:address> <wsa:referenceparameters> <myapp:privateinstance>1234</myapp:privateinstance> </wsa:referenceparameters> </RegistrationService> </CoordinationContext> </CreateCoordinationContextResponse> Identyfikator

47 38 Przebieg aktywacji Usługa wysyła żądanie CreateCoordinationContext <CreateCoordinationContext> <Expires>... </Expires>? <CurrentContext>... </CurrentContext>? <CoordinationType>... </CoordinationType>... </CreateCoordinationContext> Koordynator odsyła CreateCoordinationContextResponse <CreateCoordinationContextResponse> <CoordinationContext> <Identifier> <CoordinationType> <RegistrationService> <wsa:address> <wsa:referenceparameters> <myapp:privateinstance>1234</myapp:privateinstance> </wsa:referenceparameters> </RegistrationService> </CoordinationContext> </CreateCoordinationContextResponse> Identyfikator Adres usługi rejestracji

48 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

49 40 Rejestracja Usługa wysyła żądanie Register <Register> <ProtocolIdentifier> <ParticipantProtocolService> <wsa:address> <wsa:referenceparameters> <BetaMark>AlphaBetaGamma</BetaMark> </wsa:referenceparameters> </ParticipantProtocolService> </Register> Koordynator odpowiada RegisterResponse <RegisterResponse> <CoordinatorProtocolService> <wsa:address> <wsa:referenceparameters> <myapp:markkey>%%f03ca2b%%</myapp:markkey> </wsa:referenceparameters> </CoordinatorProtocolService> </RegisterResponse>

50 40 Rejestracja Usługa wysyła żądanie Register <Register> <ProtocolIdentifier> <ParticipantProtocolService> <wsa:address> <wsa:referenceparameters> <BetaMark>AlphaBetaGamma</BetaMark> </wsa:referenceparameters> </ParticipantProtocolService> </Register> Koordynator odpowiada RegisterResponse <RegisterResponse> <CoordinatorProtocolService> <wsa:address> <wsa:referenceparameters> <myapp:markkey>%%f03ca2b%%</myapp:markkey> </wsa:referenceparameters> </CoordinatorProtocolService> </RegisterResponse> Adres obsługi protokołu

51 40 Rejestracja Usługa wysyła żądanie Register <Register> <ProtocolIdentifier> <ParticipantProtocolService> <wsa:address> <wsa:referenceparameters> <BetaMark>AlphaBetaGamma</BetaMark> </wsa:referenceparameters> </ParticipantProtocolService> </Register> Koordynator odpowiada RegisterResponse <RegisterResponse> <CoordinatorProtocolService> <wsa:address> <wsa:referenceparameters> <myapp:markkey>%%f03ca2b%%</myapp:markkey> </wsa:referenceparameters> </CoordinatorProtocolService> </RegisterResponse> Adres obsługi protokołu Adres obsługi protokołu

52 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

53 42 Ogólny schemat interakcji Źródło:

54 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

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

56 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

57 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

58 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

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

60 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

61 50 WS-Transaction

62 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

63 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?

64 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

65 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

66 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ę

67 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

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

69 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

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

71 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

72 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

73 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

74 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

75 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

76 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

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

78 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ę

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

80 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

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

82 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

83 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

84 73 WS-ReliableMessaging

85 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

86 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

87 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

88 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

89 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

90 77 Model komunikacji Źródło: WS-ReliableMessaging Wikipedia, the free encyclopedia,

91 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

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

93 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

94 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

95 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

96 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

97 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

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

99 86 ebxml

100 87 Electronic Business Using XML (ebxml) Standard ISO 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

101 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

102 89 Format wiadomości ebxml (1)

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

104 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

105 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

106 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

107 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

108 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

109 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

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

111 94 Skąd wynika niska popularność ebxml?

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

113 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

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

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

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

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

118 96 RosettaNet

119 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

120 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

121 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

122 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

123 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

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

125 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

126 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

127 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

128 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

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

130 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

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

132 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

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

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

135 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

136 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

137 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

138 116 Format wiadomości Źródło:

139 117 Powiązane standardy

140 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.

141 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

142 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

143 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

144 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

145 123 Przykład modelu Źródło: W3C, Web Service Choreography Interface (WSCI) 1.0

146 Przykład interfejsu z ograniczeniami z modelu <wsdl:definitions name="airline" targetnamespace=" xmlns=" xmlns:defs=" xmlns:tns=" xmlns:wsdl=" <wsdl:import namespace=" location=" /> <wsdl:import namespace=" location=" /> <!-- *************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>

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