Koordynowanie procesów biznesowych w środowiskach SOA

Transkrypt

1 XVI Konferencja PLOUG Kościelisko Październik 2010 Koordynowanie procesów biznesowych w środowiskach SOA Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy Politechnika Poznańska Krzysztof.Jankiewicz@cs.put.poznan.pl Abstrakt. Długotrwałe procesy biznesowe funkcjonujące w środowiskach SOA, są często konstrukcjami złożonymi. Poszczególne ich fragmenty różnią się między sobą wieloma cechami. Realizacja części z nich jest niezbędna do osiągnięcia sukcesu procesu biznesowego, podczas gdy inne fragmenty mogą mieć charakter opcjonalnych składowych, których fiasko nie musi oznaczać rezygnacji z realizacji całego procesu. Złożoność procesu biznesowego często wynika z umieszczonej w nim obsługi najróżniejszych wyjątków, które mogą zaistnieć podczas jego realizacji. Obsługa ta często ma charakter obsługi systemowej, doprowadzając do wymieszania charakteru biznesowego i systemowego procesu. Wydaje się, że mimo istnienia całego szeregu standardów i specyfikacji związanych z przetwarzaniem długotrwałych procesów biznesowych (WS-BA, WS-BPEL), nie ma rozwiązania, które w wystarczający sposób wspomagałoby twórców procesów w ich pracy. Takim rozwiązaniem może być środowisko Koordynatora Transakcji przedstawione w ramach tego artykułu. Badania, których wyniki są przedstawione w tym artykule, zostały częściowo sfinansowane przez Ministerstwo Nauki i Szkolnictwa Wyższego z Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka projekt IT-SOA nr POIG /08, Informacja o autorach. Krzysztof Jankiewicz jest adiunktem w Instytucie Informatyki Politechniki Poznańskiej. Specjalizuje się w technologiach baz danych ze szczególnym uwzględnieniem danych XML, przestrzennych, pełnotekstowych. Brał udział w kilku dużych projektach informatycznych, kierował realizacją m.in. systemu kadrowo-płacowego wyższej uczelni, systemu informatycznego dla agencji reklamowej. Jest autorem szeregu publikacji o charakterze naukowo-technicznym. Od wielu lat prowadzi szkolenia z technologii i produktów Oracle w ramach Oracle University. W trakcie konferencji, szkół i seminariów PLOUG wielokrotnie prowadził warsztaty, tutoriale i wykłady na tematy wchodzące w zakres jego zainteresowań. Dr hab. inż. Mikołaj Morzy jest adiunktem w Instytucie Informatyki Politechniki Poznańskiej. Jego zainteresowania naukowe koncentrują się przede wszystkim na tematyce eksploracji danych, jest on autorem ponad czterdziestu publikacji dotyczących tej tematyki. Drugą dziedziną zainteresowań i głównym tematem działalności dydaktycznej Mikołaja Morzego są technologie aplikacji internetowych i rozproszonych oraz technologie związane z bazami danych i hurtowniami danych.

2

3 Koordynowanie procesów biznesowych w środowiskach SOA Wstęp Wprowadzenie semantyki transakcji do specyfikacji i przetwarzania złożonych procesów biznesowych w architekturze SOA pozwoliłoby użytkownikom, analogicznie jak w przypadku systemów baz danych i rozproszonych systemów informatycznych, na uproszczenie definiowania obliczeń w kontekście awarii i współbieżności dostępu do danych. Niestety, w systemach opartych na architekturze SOA, mamy do czynienia z asynchronicznymi, złożonymi i długotrwałymi procesami biznesowymi, w których występują luźno powiązani uczestnicy (usługi), powoduje to, że klasyczny model płaskiej transakcji (tzw. flat transaction model) a nawet transakcji zagnieżdżonej (tzw. nested transaction model), dla których cała transakcja jest jednostką atomowości, spójności, izolacji oraz trwałości, jest niewystarczający i niewłaściwy. Należy podkreślić, że problem koordynacji przetwarzania w systemach opartych na architekturze SOA został zauważony już kilka lat temu. W efekcie prac związanych z tym zagadnieniem opracowano szereg protokołów i specyfikacji wspomagających koordynację procesów i implementację przetwarzania transakcyjnego. Można do nich zaliczyć specyfikacje: WS-Coordination w wersji 1.2 [FeJe09], WS-AtomicTransaction (WS-AT) w wersji 1.2 [LiWi09] oraz WS- BusinessActivity (WS-BA) w wersji 1.2 [FrLi09], a także specyfikację języka WS-BPEL (Web Services Business Process Execution Language) [AAA+09]. Struktura artykułu jest następująca. W rozdziale drugim przedstawione zostały główne wnioski z analizy wymienionych wyżej specyfikacji. Rozdział trzeci omawia charakterystykę procesu biznesowego, podczas gdy rozdział czwarty zawiera opis architektury Koordynatora Transakcji. Rozdział piąty poświecony został implementacji zrealizowanej przy wykorzystaniu narzędzia Oracle BPEL Process Manager. Podsumowanie zawarto w rozdziale szóstym. 2. Aktualne specyfikacje Analiza obecnie wspomnianych we wstępie specyfikacji, wspomagających koordynację procesów i implementację przetwarzania transakcyjnego, pozwala zauważyć, że każda z nich posiada pewnego rodzaju ograniczenia, niekiedy też jej użycie wymaga spełnienia szeregu warunków. WS-AT jest przeznaczona tylko dla krótkotrwałych aktywności i nie nadaje się do koordynowania aktywności biznesowych trwających często okres czasu mierzony w dniach lub miesiącach. W ramach tej specyfikacji możliwa jest koordynacja usług, które muszą funkcjonować w zgodnie z ustalonymi warunkami. Przykładowo działania podejmowane przez usługi muszą być realizowane w ramach lokalnych transakcji posiadających własności izolacji i atomowości. Ponadto przetwarzanie musi być wstrzymane w końcowym etapie przetwarzania aktywności i w zależności od sposobu zakończenia aktywności, powinno być zatwierdzane lub wycofywane. Ograniczenia te z oczywistych względów nie są możliwe do spełnienia w każdym przypadku. WS-BA jest specyfikacją przeznaczoną do długotrwałych transakcji biznesowych. Podobnie jak w przypadku WS-AT została ona oparta o specyfikację WS-Coordination co determinuje wykorzystanie procesu koordynatora aktywności oraz wykorzystanie protokołów do komunikowania się pomiędzy uczestnikami aktywności a jej koordynatorem. Jednak w odróżnieniu od specyfikacji WS-AT, która definiuje zarówno protokoły wykorzystywane do współpracy pomiędzy koordynatorem a inicjatorem aktywności, jak również pomiędzy koordynatorem a innymi uczestnikami aktywności (usługami składowymi), specyfikacja WS-BA definiuje jedynie protokoły wykorzystywane do komunikacji pomiędzy koordynatorem a uczestnikami aktywności innymi niż inicjator aktywności. Wynika to z faktu, iż reguły zatwierdzania lub wycofania transakcji biznesowych mogą być bardzo złożone i zgodnie z intencją specyfikacji WS-BA należą one do jej sfery biznesowej. W rezultacie rozwiązania oparte na specyfikacji WS-BA są w ogólności bardzo skompliko-

4 20 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy wane. Twórca procesu biznesowego musi samodzielnie opracować protokół współpracy pomiędzy inicjatorem aktywności a koordynatorem. Alternatywnym rozwiązaniem jest całkowita integracja koordynatora i jego mechanizmów z inicjatorem aktywności, który realizuje proces biznesowym. Rozwiązanie takie prowadzi często do wymieszania elementów biznesowych (wynikających z definicji procesu biznesowego) z mechanizmami systemowymi (wynikającymi z potrzebą koordynacji transakcji), co znacząco wpływa na prostotę i czytelność definicji procesu. Kolejną różnicą pomiędzy specyfikacją WS-AT, a WS-BA jest to, że ta druga zezwala na to aby efekty działania usług uczestniczących w procesie biznesowym miały charakter trwały, a także nieodwracalny, jeszcze zanim proces biznesowy zostanie ukończony. W efekcie, fiasko procesu biznesowego wymaga podjęcia odpowiednich akcji kompensacyjnych. Zgodnie ze specyfikacją WS-BA za operacje kompensacyjne odpowiedzialne są usługi będące uczestnikami aktywności. Inicjacja operacji kompensacyjnych realizowana jest za pomocą komunikatu wysyłanego do poszczególnych usług. Rozwiązanie przyjęte przez specyfikację WS-BA umożliwia jednak jedynie pełną kompensacje działań podjętych przez wszystkie bądź wybrane usługi, nie ma możliwości kompensacji tylko wybranych przez twórcę procesu biznesowego akcji. Specyfikacja WS-BPEL pozwala na definiowanie procesów biznesowych, które w swych założeniach mogą być długotrwałe (LRT). Niestety rozwiązania przyjęte przez specyfikację WS-BPEL zakładają, że elementy takie jak obsługa wyjątków, czy podejmowanie odpowiednich akcji kompensujących należą do twórcy procesu biznesowego. Zatem i tu, podobnie jak w przypadku specyfikacji WS-BA, mamy do czynienia z procesem definiującym elementy biznesowe jak i elementy o charakterze systemowym. Niestety, w odróżnieniu od specyfikacji WS-BA, gdzie kompensacja usługi inicjowana jest za pomocą prostego komunikatu, w przypadku WS-BPEL, twórca procesu biznesowego w celu wykonania działań kompensujących musi zadeklarować wywołanie odpowiednich usług przekazując podczas wywołań odpowiednie parametry. W efekcie definiowanie poprawnie zaprojektowanych procesów biznesowych, jest zadaniem skomplikowanym i wymagającym dużej znajomości wywoływanych usług i ich kompensacyjnych odpowiedników. Na koniec, należy zauważyć, że zarówno specyfikacja WS-BPEL jak i WS-BA w żaden sposób nie nawiązują do problemów związanych ze współbieżną realizacją wielu procesów biznesowych. Powyższe cechy wymienionych specyfikacji skłaniają do zaproponowania takiego rozwiązania, które w znaczący sposób ułatwi tworzenie procesów biznesowych, rozdzieli warstwę biznesową od systemowej, umożliwi tworzenie długotrwałych procesów biznesowych wykorzystujących różnorodne usługi składowe nie koniecznie posiadające określone cechy. Rozwiązanie to powinno umożliwiać odpowiednią koordynację procesów biznesowych w fazie akceptacji (lub odrzucenia), powinno dawać możliwość dokonywania częściowej kompensacji oraz powinno uwzględniać potrzebę wzajemnej koordynacji współbieżnie wykonywanych procesów. 3. Charakterystyka procesów biznesowych Zanim przejdziemy do omówienia zaproponowanego przez nas rozwiązania, dokonamy analizy wymaganych cech procesów biznesowych Złożoność procesu biznesowego W systemach zarządzania baz danych dominuje model przetwarzania oparty na transakcjach posiadających własności ACID [BHG87], w środowiskach opartych na architekturze SOA wykonywanie procesów biznesowych wymaga zastosowania bardziej elastycznych rozwiązań [MTSS03]. Wynika to z tego, że procesy biznesowe bazują na usługach sieciowych, które są luźno ze sobą powiązane, a także z tego, że są to procesy, które nierzadko posiadają złożoną definicję, składającą się z wielu zagnieżdżonych konstrukcji o różnorodnej charakterystyce, ponadto, ich czas trwania może być mierzony w dniach lub miesiącach. Kolejną istotną różnicą jest sposób

5 Koordynowanie procesów biznesowych w środowiskach SOA 21 reakcji na awarie. W przypadku systemów zarządzania bazami danych z reguły obsługa awarii, która ma miejsce w ramach transakcji, polega na systemowym wykonaniu szeregu czynności mających na celu powrót do stanu sprzed rozpoczęcia transakcji. W procesach biznesowych czynności podejmowane w wyniku awarii mogą mieć odmienny charakter, wynika to z faktu, że kształt tych czynności jest często ściśle uzależniony od miejsca awarii w procesie biznesowym. Rozważmy przykład zakupu towaru w sklepie internetowym, proces tego typu może składać się z wielu etapów obejmujących np. złożenie zamówienia, zapłatę za towar, wyprodukowanie towaru, transport towaru do magazynu, dostarczenie towaru do klienta, odbiór towaru. Z punktu widzenia biznesowego zupełnie inne akcje powinny być podjęte w sytuacji, gdy proces ulegnie awarii w wyniku zniszczenia towaru podczas transportu do magazynu (towar powinien być na nowo wyprodukowany i dostarczony do magazynu, po czym proces może być kontynuowany), a zupełnie inne gdy awaria procesu nastąpi w wyniku rezygnacji klienta z zakupionego towaru podczas jego odbioru (towar może zostać z powrotem umieszczony w magazynie). Powyższy przykład wykazuje, że na pewnym poziomie abstrakcji podejście systemowe oparte o mechanizmy transakcyjne nie jest właściwe. Nie zmienia to jednakże faktu, iż automatyzacja i systemowość na niższych poziomach procesu biznesowego mogą być bardzo przydatne. Wyobraźmy sobie złożoność procesu biznesowego, który po każdym kroku, każdym wywołaniu usługi, określa sposób reakcji na awarie, jakie w tym miejscu mogą wystąpić. Proces taki, z punktu widzenia definicji, byłby bardzo skomplikowany. Tymczasem większość procesów biznesowych składa się z szeregu złożonych zadań (podprocesów), opartych dla przykładu na wywołaniu szeregu usług składowych. Wyodrębnienie takich zadań pod postacią transakcji posiadających określone cechy i w sposób systemowy reagujących na zaistniałe w ich wnętrzu awarie, pozwoliłoby znacząco uprościć definicję procesów biznesowych, pozwalając ich twórcom skoncentrować się na zagadnieniach o charakterze biznesowym. Zakładamy zatem, że proces biznesowy może składać się z szeregu transakcji. Awaria procesu biznesowego wymaga od twórcy procesu zdefiniowania odpowiednich akcji, które uwzględnią fakt, iż do czasu awarii część transakcji występujących w procesie biznesowym została wykonana i zatwierdzona. Akcje te definiowane są przez twórcę procesu gdyż mają one z reguły charakter biznesowy. Twórca procesu biznesowego nie musi natomiast troszczyć się o akcje zrealizowane w ramach tych transakcji, które do momentu wystąpienia awarii się nie zakończyły. Ich wycofaniem lub kompensacją zajmują się mechanizmy systemowe transakcji Opcjonalność i obligatoryjność Tak jak zostało to wspomniane wcześniej, procesy biznesowe nierzadko posiadają złożoną definicję, składającą się z wielu zagnieżdżonych konstrukcji o różnorodnej charakterystyce. Aby odwzorować tę złożoność zakładamy, że każda transakcja, podobnie jak proces biznesowy, może być skonstruowana przy użyciu transakcji podrzędnych. Ponadto, zakładamy, że każda z transakcji podrzędnych powinna posiadać własność informującą o tym, czy jej prawidłowe zakończenie jest warunkiem sukcesu nadrzędnej. Pozwoliłoby to w prosty sposób definiować obligatoryjne i opcjonalne składowe transakcji. Aby uzasadnić takie rozwiązanie rozważmy transakcję organizującą zagraniczny wyjazd, zawierającą trzy, kolejno wykonywane, transakcje podrzędne odpowiedzialne za: rezerwację hotelu, zakup biletu na samolot oraz zamówienie taksówki na lotnisko. Nie chcąc aby fiasko transakcji podrzędnej związanej z zamówieniem taksówki było powodem wycofania całej transakcji związanej z wyjazdem, możemy zdefiniować ją jako opcjonalną Zależność i niezależność składowych Kolejną własnością transakcji podrzędnych powinna być zależność lub niezależność od końcowego sukcesu transakcji nadrzędnej. W przypadku transakcji niezależnych, efekty dokonanych przez nie akcji, nie będą zależeć od sukcesu lub porażki transakcji nadrzędnej. W przypadku transakcji zależnych, akcje przez nie podjęte mogą zostać wycofane lub skompensowane nie tylko

6 22 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy na podstawie wycofania transakcji podrzędnej, ale także w wyniku fiaska transakcji nadrzędnej. Ponownie rozważmy transakcję przedstawioną w poprzednim akapicie. Załóżmy, że rezerwacja hotelu oraz zakup biletu na samolot wymaga uiszczenia niezwrotnej zapłaty za skorzystanie z odpowiednich usług. W związku z tym transakcja podrzędna, odpowiedzialna za dokonanie wspomnianej zapłaty, umieszczona przed pozostałymi podrzędnymi transakcjami będzie niezależna nie będzie przedmiotem wycofania lub kompensacji, nawet w przypadku fiaska transakcji nadrzędnej. Pozostałe trzy transakcje podrzędne będą zależne, przykładowo zakończona transakcja obejmująca rezerwację hotelu będzie mogła zostać skompensowana w przypadku fiaska transakcji, odpowiedzialnej za zakup biletu na samolot, która jako obowiązkowa spowoduje wycofanie transakcji podstawowej Częściowe wycofanie transakcji Aby zwiększyć przepustowość systemu przetwarzającego procesy biznesowe, każda wykorzystywana transakcja powinna móc definiować punkty zachowania. Pozwalają one, w przypadku wystąpienia awarii, na częściowe wycofanie (kompensację) podjętych akcji, a następnie wznowienie działań, poprzez ponowienie tych samych czynności lub np. podjęcie czynności alternatywnych. Przykładowo fiasko zakupu biletu na samolot w ramach omawianej transakcji, może zainicjować podjęcie alternatywnych działań, mających na celu zakup biletu, przy wykorzystaniu innych linii lotniczych i nie musi oznaczać automatycznego wycofania całej transakcji. Mając na uwadze omówioną powyżej charakterystykę procesów biznesowych, a także fakt, iż obowiązujące specyfikacje, w chwili obecnej, nie ułatwiają, w sposób wystarczający, definiowania procesów, które funkcjonowałyby zgodnie z tą charakterystyką, postanowiliśmy zaprojektować i zaimplementować środowisko Koordynatora Transakcji. 4. Architektura Koordynatora Transakcji Koordynator Transakcji ma budowę modułową. Poniżej scharakteryzowano moduły wchodzące w skład Koordynatora Transakcji. Moduł Definiowania Transakcji moduł, którego zadaniem jest umożliwienie użytkownikowi końcowemu definiowanie procesu biznesowego z wykorzystaniem poleceń sterujących przetwarzaniem transakcji. Definicja procesu biznesowego ma postać definicji procesu BPEL uzupełnionego o polecenia sterujące przetwarzaniem transakcji. Definicja ta jest nazywana w ramach systemu Definicją Transakcji lub Plikiem Definicji Transakcji. Moduł Zarządcy Transakcji (MZT) zadaniem tego modułu jest realizacja poleceń zawartych Pliku Definicji Transakcji. W szczególności rolę MZT może pełnić dowolny serwer procesów BPEL posiadający funkcjonalność pozwalającą na jego rozbudowę tak aby była możliwa interpretacja poleceń sterujących przetwarzaniem transakcji. Moduł Konstrukcji Transakcji w związku z tym, że polecenia sterujące przetwarzaniem transakcji nie wchodzą w skład standardu języka BPEL, oraz że wymagają one w ramach naszego systemu podjęcia całego szeregu czasami skomplikowanych akcji, wymagają one odpowiedniej interpretacji i przetwarzania. W naszym rozwiązaniu zadanie to realizuje Moduł Konstrukcji Transakcji. Funkcjonuje on w ramach MZT reagując na odpowiednie fragmenty procesów BPEL wymagające ponadstandardowych akcji. Moduł Zarządzania Współbieżnym Dostępem (MZWD) jest modułem, który ma na celu zarządzanie zbiorem równolegle wykonywanych instancji procesów. W celu zarządzania współbieżnym zbiorem procesów współpracuje on z Lokalnymi Zarządcami Spójności (LZS) funkcjonującymi po stronie dostawców usług. Lokalni Zarządcy Zasobów obsługują definicje kompatybilności usług dostarczanych przez określonego dostawcę oraz utrzymują

7 Koordynowanie procesów biznesowych w środowiskach SOA 23 grafy konfliktowej uszeregowalności związane z wywoływaniem obsługiwanego zbioru usług. Z punktu widzenia specyfikacji WS-Coordination moduł ten pełni rolę koordynatora. Moduł Akceptacji Transakcji (MAT) zadaniem tego modułu jest koordynacja procesu akceptacji obejmująca akcje związane z: rozpoczynaniem transakcji, zatwierdzaniem transakcji, wycofywaniem transakcji, tworzeniem punktów zachowania, oraz wycofywaniem do punktu zachowania. Z punktu widzenia specyfikacji WS-Coordination ten moduł również pełni rolę koordynatora. Plik Definicji Transakcji to definicja procesu BPEL uzupełniona o polecenia sterujące przetwarzaniem transakcji i inne deklaracje związane z ich sposobem realizacji. Architekturę systemu przedstawia rys. 1. Rys. 1. Architektura Koordynatora Transakcji Poniżej scharakteryzowano szczegółowo sposób funkcjonowania Koordynatora Transakcji Plik Definicji Transakcji Tak jak zostało to wspomniane przy opisie modułów Koordynatora Transakcji, definicja transakcji to definicja procesu biznesowego wyrażona w języku BPEL. Taki wybór wynikał ze stosunkowo dużej popularności języka BPEL oraz z istnienia wielu serwerów, które umożliwiają wykonywanie procesów biznesowych w nim wyrażonych. W specyfikacji języka BPEL nie istnieją konstrukcje umożliwiające bezpośrednie odwoływanie się do semantyki poleceń sterujących transakcjami. Wymagało to zatem zastosowania rozszerzeń języka BPEL. Rozszerzenia te mogą mieć różną postać, zależną najczęściej od serwera procesów biznesowych, w ramach którego będą wykonywane. Przykładowo w przypadku Apache ODE 2.0 można wykorzystać dostępne w nim rozszerzenia mające postać wstawek umieszczonych w definicji procesu w znacznikach <bpel:extensionactivity> jak na poniższym przykładzie. <bpel:extensionactivity> <ext:begintransaction transname="trans0_2mat" transnamemzwd="trans0_2mzwd" parentname="transmain0mat"> <Independent>no</Independent> <Mandatory>no</Mandatory> </ext:begintransaction> </bpel:extensionactivity> Aby umożliwić tworzenie procesów biznesowych posiadających wymagane przez nas własności zdefiniowaliśmy następujące rozszerzenia języka BPEL: begintransaction rozpoczyna transakcję, w tym również transakcję zagnieżdżoną.

8 24 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy preinvoke jedyne rozszerzenie mające charakter systemowy, dzięki niemu istnieje możliwość wykonania koniecznych czynności związanych z wywołaniem usługi w ramach transakcji. savepoint zadaniem tego rozszerzenia jest stworzenie tzw. punktu zachowania umożliwiającego transakcji biznesowej dokonanie kompensacji (wycofanie) części wywołań usług składowych. rollback zadaniem tego rozszerzenia jest wykonanie kompensacji całej transakcji lub części z wywołanych w jej ramach usług składowych. commit zadaniem rozszerzenia commit jest zatwierdzenie całej transakcji i jej ostateczne zakończenie. Oczywiście pod każdym rozszerzeń kryć muszą się odpowiednie akcje o charakterze systemowym. Tylko dzięki takim akcjom transakcje definiowane w ramach procesu biznesowego mogą pozostawać proste w swej definicji, jednocześnie zachowując podczas wykonywania zadeklarowane cechy Moduł Definiowania Transakcji Zadaniem Modułu Definiowania Transakcji jest umożliwienie użytkownikowi końcowemu definiowania procesu biznesowego z wykorzystaniem poleceń sterujących przetwarzaniem transakcji Po przeanalizowaniu różnych możliwości zdecydowaliśmy na wykorzystanie platformy Eclipse. Jest ona w chwili obecnej bardzo popularna, pozwala na definiowanie procesów biznesowych w języku BPEL (Eclipse BPEL Designer), i co najważniejsze posiada duże możliwości rozbudowy. Stworzona przez nas wtyczka znacząco ułatwia definiowanie rozszerzeń sterujących transakcjami, przekształcając edytor definicji procesów biznesowych BPEL funkcjonujący w ramach platformy Eclipse w Moduł Definiowania Transakcji. Definiowanie wspomnianych rozszerzeń może odbywać się w sposób wizualny. Na rysunku 2. widać początkową postać definicji procesu biznesowego, w zakładce będącej paletą narzędzi można zauważyć na dole paletę dotyczącą rozszerzeń transakcyjnych. Za pomocą mechanizmu drag and drop można uzupełnić definicję procesu o rozszerzenia będące rozpoczęciem transakcji, zatwierdzeniem transakcji, deklaracją wywołania usługi itd. Dla każdego rozszerzenia posiadającego możliwe do zdefiniowania własności, Moduł Definiowania Transakcji umożliwia ich wizualną edycję, przykładowo na rysunku 3. przedstawiona jest edycja własności rozszerzenia begintransaction. Końcowa postać prostego procesu biznesowego wykorzystującego pojedynczą transakcję została przedstawiona na rysunku 4. Moduł Definiowania Transakcji w sposób automatyczny uzupełnia definicję procesu o istotne, z punktu widzenia wykorzystywanych rozszerzeń, składowe. Na rysunku 6. przedstawiono fragment definicji procesu obejmujący rozszerzenia języka BPEL. Moduł Definiowania Transakcji może być wykorzystany nie tylko do definiowania prostych procesów biznesowych składających się z pojedynczych transakcji, ale także złożonych procesów biznesowych wykorzystujących wiele transakcji, w tym transakcje zagnieżdżone. Fragment graficznej reprezentacji procesu złożonego przedstawiono na rysunku 5.

9 Koordynowanie procesów biznesowych w środowiskach SOA 25 Rys. 2. Początkowa postać procesu Rys. 3. Edycja własności rozszerzenia Rys. 4. Końcowa postać procesu Rys. 5. Graficzna reprezentacja procesu złożonego Rys. 6. Rozszerzenie języka BPEL (Apache ODE)

10 26 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy 4.3. Moduł Zarządcy Transakcji Modułem Zarządcy Transakcji (MZT) jest serwer języka BPEL. Jego zadaniem jest wykonywanie operacji zawartych w procesach zdefiniowanych przy wykorzystaniu języka BPEL. Oprócz czynności wynikających bezpośrednio z instrukcji języka BPEL, dzięki rozszerzeniom języka BPEL i zaimplementowanej obsłudze rozszerzeń, współpracuje on dodatkowo z innymi modułami Koordynatora Transakcji, przykładowo z Modułem Akceptacji Transakcji. Każdorazowe pojawienie się rozszerzenia w definicji procesu BPEL powoduje przeniesienie przetwarzania do implementacji rozszerzenia. Dzięki temu możliwe jest, w ramach procesu biznesowego, wykonywanie niezbędnych, dodatkowych działań np. mających na celu sterowanie i koordynację procesu. Z punktu widzenia architektury systemu obsługą rozszerzeń zajmuje się Moduł Konstrukcji Transakcji. Dla większej czytelności artykułu został on omówiony po przedstawieniu modułów, z którymi współpracuje Moduł Akceptacji Transakcji Moduł Akceptacji Transakcji został zaimplementowany w oparciu o specyfikację WS- Coordination. Jego zadaniem jest koordynacja procesu transakcji w zakresie: aktywacji transakcji, rejestracji punktów zachowania, akceptacji transakcji, wycofania częściowego transakcji (do wskazanego punktu zachowania), wycofania pełnego transakcji. Z punktu widzenia specyfikacji WS-Coordination MAT pełni rolę procesu koordynatora i z tego powodu udostępnia następujące usługi: Aktywacji zadaniem usługi aktywacji jest stworzenie tzw. kontekstu koordynacji, który pełni rolę identyfikatora transakcji wspólnego dla wszystkich uczestników pojedynczej instancji transakcji wykonywanej w ramach procesu biznesowego. Usługę aktywacji funkcjonującą w ramach MAT wywołuje MZT, w rezultacie otrzymuje kontekst koordynacji. Kontekst koordynacji jest wykorzystywany przez niego podczas rejestracji jako uczestnika aktywności. Ponadto kontekst koordynacji przekazywany jest (w nagłówkach komunikatów) usługom wywoływanym w ramach transakcji, dzięki temu mogą one również zarejestrować się jako uczestnicy tej samej koordynowanej aktywności. Rejestracji zadaniem tej usługi jest rejestracja uczestnika aktywności na podstawie przesłanego przez niego kontekstu koordynacji. Uczestnicy aktywności mogą pełnić różną rolę w procesie jej koordynacji, i tak dla MAT uczestnikiem aktywności będą zarówno MZT przetwarzający Plik Definicji Transakcji jak i usługi składowe wywoływane na podstawie zapisów w Pliku Definicji Transakcji. Zgodnie ze specyfikacją WS-Coordination MAT komunikuje się z uczestnikami aktywności za pomocą określonych protokołów. Protokoły te wynikają z typów koordynacji ustalanych podczas tworzenia kontekstu koordynacji. W przypadku MAT opracowane zostały dwa protokoły. Pierwszy z nich EnhancedCompletion wykorzystywany jest do współpracy MAT z inicjatorem aktywności Modułem Zarządcy Transakcji. Drugi z protokołów Enhanced2PC wykorzystywany jest natomiast do współpracy MAT z innymi uczestnikami aktywności usługami składowymi. Poniżej przedstawiono każdy z protokołów, jego komunikaty, a także diagram stanów Protokół EnhancedCompletion Protokół EnhancedCompletion jest wykorzystywany w komunikacji pomiędzy nadzorującym wykonanie transakcji Modułem Zarządcy Transakcji, zwanym poniżej inicjatorem aktywności, a procesem koordynatora Modułem Akceptacji Transakcji. Komunikaty wymieniane w ramach tego protokołu są następujące:

11 Koordynowanie procesów biznesowych w środowiskach SOA 27 RegisterInvocation wysyłany przez inicjatora aktywności. Każdorazowo przed wywołaniem usługi składowej MZT wysyła do MAT informację o fakcie wywołania określonej usługi komunikat RegisterInvocation. Koordynator zapisuje tę informację w dzienniku wycofania i potwierdza inicjatorowi fakt przyjęcia i zapisania tej informacji komunikat RegisterInvocationResponse. Dopiero po otrzymaniu odpowiedzi MZT może wykonywać dalsze działania np. wywołać określoną usługę składową. RegisterInvocationResponse wysyłany przez MAT w odpowiedzi na komunikat Register- Invocation. Potwierdza on tym samym fakt zarejestrowania wywołania usługi składowej w dzienniku wycofania. Savepoint - wysyłany przez inicjatora aktywności w celu zarejestrowania przez MAT faktu zaistnienia w procesie biznesowym punktu zachowania. Zadaniem punktów zachowania jest tworzenie nazwanych miejsc w transakcjach, do których będzie możliwość skompensowania przetwarzania. W momencie pojawienia się w Pliku Definicji Transakcji instrukcji utworzenia punktu zachowania, MZT (inicjator) wysyła do MAT (koordynator) informację o jego zaistnieniu w komunikacie Savepoint. Koordynator zapisuje informację o punkcie zachowania w dzienniku wycofania i potwierdza ten fakt inicjatorowi za pomocą komunikatu SavepointResponse. Po otrzymaniu potwierdzenia MZT może realizować dalsze działania. SavepointResponse wysyłany przez MAT w odpowiedzi na komunikat Savepoint. Potwierdza on tym samym fakt zarejestrowania punktu zachowania w dzienniku wycofania. Commit - wysyłany przez inicjatora aktywności w celu zainicjowania przez MAT procedury zatwierdzenia i zakończenia transakcji. Commited wysyłany przez MAT po zatwierdzeniu transakcji. Komunikat ten pełni rolę odpowiedzi na komunikat Commit i potwierdza fakt zatwierdzenia i zakończenia transakcji. Rollback wysyłany przez inicjatora aktywności w celu zainicjowania przez MAT procedury wycofania i zakończenia transakcji. Aborted wysyłany przez MAT do inicjatora aktywności w dwóch sytuacjach: jako potwierdzenie wykonania akcji wycofywania transakcji w wyniku komunikatu Rollback, albo jako informacja o zakończonym niepowodzeniem zatwierdzeniu transakcji. SavepointRollback wysyłany przez inicjatora aktywności w celu zainicjowania przez MAT procedury skompensowania (wycofania) transakcji do wskazanego punktu zachowania. W momencie pojawienia się w Pliku Definicji Transakcji instrukcji wycofania do punktu zachowania, MZT (inicjator) wysyła do MAT (koordynator) informację o tym fakcie w komunikacie SavepointRollback. Koordynator przy współpracy z uczestnikami aktywności i na podstawie zapisów w dzienniku wycofania wykonuje operacje kompensacji dla tych akcji, które miały miejsce od wystąpienia punktu zachowania o określonej nazwie. Następnie potwierdza fakt wykonania czynności inicjatorowi za pomocą komunikatu SavepointAborted. Po otrzymaniu potwierdzenia MZT może kontynuować wycofaną w części transakcję. SavepointAborted wysyłany przez MAT do inicjatora aktywności jako potwierdzenie wykonania akcji wycofywania transakcji do punktu zachowania. Diagram stanów dla protokołu EnhancedCompletion został przedstawiony na rys.7.

12 28 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy Rys. 7. Diagram stanów dla protokołu EnhancedCompletion Rys. 8. Diagram stanów dla protokołu Enhanced2PC Protokół Enhanced2PC Protokół Enhanced2PC jest wykorzystywany w komunikacji pomiędzy usługami składowymi wykorzystywanymi w procesie biznesowym a procesem koordynatora MAT. Komunikaty wymieniane w ramach protokołu Enhanced2PC są następujące: RegisterCompensation zadaniem komunikatu jest przekazanie przez uczestnika aktywności (usługa składowa) informacji do MAT o usłudze kompensacji związanej z danym wywołaniem usługi składowej. Usługi składowe przy każdym wywołaniu, po (lub przed) wykonaniu akcji, wysyłają do MAT (koordynator) informację wskazującą na usługę kompensującą, której zadaniem jest kompensacja efektów wywołania usługi komunikat Register- Compensation. Koordynator zapisuje tę informację w dzienniku wycofania (razem z zapisaną już wcześniej informacją o wywołaniu usługi) i potwierdza usłudze składowej fakt przyjęcia i zapisania tej informacji komunikat RegisterCompensationResponse. RegisterCompensationResponse wysyłany przez MAT do uczestnika aktywności jako potwierdzenie zarejestrowania usługi kompensacji. Prepare powiadamia uczestnika o tym, że aktywność wchodzi w pierwszą fazę protokołu zatwierdzania dwufazowego i powinien on głosować za możliwym zatwierdzeniem transakcji (komunikat Prepared). Jeżeli transakcja nie jest znana uczestnikowi, wówczas musi on głosować za wycofaniem transakcji (komunikat Aborted). Jeżeli uczestnik dokonał już wcześniejszego wyboru i głosował już w sprawie danej transakcji, powinien wysłać komunikat o takiej samej treści. Prepared informuje koordynatora o tym, że uczestnik aktywności jest gotowy i głosuje za zatwierdzeniem transakcji. Commit powiadamia uczestnika o tym, że należy doprowadzić do zatwierdzenia transakcji. Komunikat ten może być wysłany tylko po pierwszej fazie protokołu i jedynie w przypadku gdy wszyscy uczestnicy transakcji zagłosowali za jej zatwierdzeniem. Jeżeli uczestnik transakcji nie posiada informacji na temat danej transakcji musi wysłać komunikat Commited do koordynatora. Commited za pomocą tego komunikatu koordynator (MAT) jest informowany, że uczestnik zatwierdził zmiany dotyczące transakcji. Taki uczestnik może zostać bezpiecznie skasowany z pamięci koordynatora. Rollback powiadamia uczestnika aktywności o tym, że należy wycofać transakcję i zapomnieć o jej istnieniu. Komunikat z tą informacją może być wysłany zarówno w pierwszej jak i w drugiej fazie protokołu.

13 Koordynowanie procesów biznesowych w środowiskach SOA 29 Aborted informuje koordynatora (MAT), że uczestnik wycofał transakcję, a także nie przechowuje już o niej żadnej informacji. ReadOnly informuje koordynatora, że uczestnik głosuje za zatwierdzeniem transakcji oraz, że nie przechowuje on już informacji o danej transakcji. Uczestnik nie będzie uczestniczył w drugiej fazie protokołu.. Diagram stanów dla protokołu Enhanced2PC został przedstawiony na rys Mechanizm zarządzania współbieżną realizacją procesów biznesowych W ramach Koordynatora Transakcji został zaimplementowany także mechanizm zarządzania współbieżną realizacją procesów biznesowych. Został on oparty o Moduł Zarządzania Współbieżnym Dostępem (MZWD) oraz z Lokalnych Zarządców Spójności (LZS), którzy zostali zaprojektowani i zaimplementowani ze względu na zastosowane przez nas podejście. Należy w tym miejscu zaznaczyć, że rozwiązanie, które wykorzystaliśmy było w znaczący sposób zainspirowane pomysłem zaprezentowanym w ramach pracy [ADN06]. Szczegóły przyjętego przez nas rozwiązania zostały zaprezentowane poniżej Wykorzystywane moduły Moduł Zarządzania Współbieżnym Dostępem z punktu widzenia specyfikacji WS- Coordination pełni on rolę koordynatora, podobnie jak Moduł Akceptacji Transakcji. Różnica polega na charakterze tej roli. MZWD odpowiada za koordynację procesu biznesowego w zakresie zarządzania współbieżną realizacją procesów biznesowych. Moduł Zarządcy Transakcji serwer procesów biznesowych wraz z Modułem Konstrukcji Transakcji (obsługującym rozszerzenia języka BPEL). Jest on odpowiedzialny za utworzenie kontekstu koordynacji w ramach wymagającej tego transakcji, rejestrację jako jednego z uczestników aktywności w ramach kontekstu, przekazywanie kontekstów koordynacji do wywoływanych usługach składowych i komunikację z koordynatorem w ramach ustalonego protokołu. Wymienione czynności wynikają z mechanizmów zarządzania współbieżną realizacją procesów biznesowych. Ponadto MZT realizuje szereg innych działań jako serwer procesów biznesowych, nie związanych z kontrolą współbieżnej realizacji procesów biznesowych, np. wywołuje zgodnie z definicją procesów usługi składowe. Lokalny Zarządca Spójności z punktu widzenia specyfikacji WS-Coordination funkcjonuje jako usługa protokołu, lub po prostu uczestnik aktywności. Po stronie każdego dostawcy usług, który udostępnia usługi będące między sobą w konflikcie (biznesowym), zainstalowana jest pojedyncza instancja LZS. Tam też definiowana jest macierz usług konfliktowych, z której korzysta LZS przy wykrywaniu wywołań usług konfliktowych. Podczas wywoływania usług, w ramach poszczególnych transakcji, LZS na podstawie macierzy usług konfliktowych utrzymuje lokalny graf konfliktowej uszeregowalności Moduł Zarządzania Współbieżnym Dostępem Jak już wspomniano, z punktu widzenia specyfikacji WS-Coordination, MZWD pełni rolę koordynatora. W związku z tym udostępnia on między innymi usługi aktywacji kontekstu koordynacji, oraz rejestracji w ramach utworzonego kontekstu koordynacji. Funkcjonują one w sposób analogiczny jak w przypadku omówionego wcześniej Modułu Akceptacji Transakcji, dlatego nie będą w tymi miejscu szczegółowo omawiane. Różnica polega na innych uczestnikach aktywności oraz na innych protokołach wykorzystywanych do komunikacji pomiędzy koordynatorem a uczestnikami aktywności. W przypadku MZWD wykorzystywane są dwa protokoły, które zostały opisane poniżej.

14 30 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy Protokół TransactionFinalizationProtocol Protokół TransactionFinalizationProtocol służy do komunikacji pomiędzy koordynatorem (MZWD) a Modułem Zarządcy Transakcji. W ramach protokołu wysyłane są następujące komunikaty: od Modułu Zarządcy Transakcji do koordynatora: Complete komunikat będący instrukcją zatwierdzenia transakcji. Po odbiorze tego komunikatu koordynator rozpoczyna algorytm zatwierdzania, czyli wysyła komunikat Complete w ramach protokołu ConcurrentAccessControlProtocol do Lokalnych Zarządców Spójności będących uczestnikami koordynowanej aktywności. Close komunikat informujący koordynatora o fakcie zakończenia koordynowanej transakcji. Po odbiorze tego komunikatu koordynator informuje Lokalnych Zarządców Spójności o zakończeniu transakcji i możliwości usunięcia wpisów na jej temat (wysyła komunikat Close w ramach protokołu ConcurrentAccessControlProtocol). Savepoint komunikat informujący koordynatora o fakcie utworzenia punktu zachowania. Rollback komunikat będący instrukcją wycofania transakcji. Komunikat rozpoczyna algorytm wycofywania transakcji, czyli wysłanie komunikatów Rollback w ramach protokołu ConcurrentAccessControlProtocol do Lokalnych Zarządców Spójności będących uczestnikami koordynowanej aktywności. SavepointRollback komunikat będący instrukcją częściowego wycofania transakcji. Komunikat rozpoczyna algorytm częściowego wycofywania, czyli wysłanie komunikatów SavepointRollback w ramach protokołu ConcurrentAccessControlProtocol. od koordynatora do Modułu Zarządcy Transakcji: Completed komunikat informujący o zakończeniu zatwierdzania transakcji przez MZWD i możliwości kontynuowania tego procesu. Komunikat jest zezwoleniem na zakończenie zatwierdzania transakcji. W sytuacji gdy zatwierdzanie przebiegnie pomyślnie kolejnym krokiem jest wysłanie przez Moduł Zarządcy Transakcji komunikatu Close, jeśli wystąpią problemy podczas zatwierdzania wówczas MZT może wysłać komunikat Rollback. Closed informuje MZT o fakcie zakończenia obsługi koordynowanej transakcji. Aborted informuje MZT o fakcie zakończenia wycofywania koordynowanej transakcji. SavepointAborted komunikat informujący MZT o fakcie zakończenia częściowego wycofywania koordynowanej transakcji. Compensate komunikat informujący MZT o potrzebie dokonania wycofania/kompensacji koordynowanej transakcji ze względu na mechanizm zarządzania współbieżną realizacją procesów. Przykładem takiej sytuacji może być pełne wycofanie transakcji poprzedzającej koordynowaną transakcję. Rysunek 9. przedstawia diagram stanów protokołu TransactionFinalizationProtocol.

15 Koordynowanie procesów biznesowych w środowiskach SOA 31 Rys. 9. Diagram stanów dla protokołu TransactionFinalizationProtocol Rys. 10. Diagram stanów dla protokołu ConcurrentAccessControlProtocol Protokół ConcurrentAccessControlProtocol Protokół ConcurrentAccessControlProtocol służy do komunikacji pomiędzy koordynatorem (Modułem Zarządzania Współbieżnym Dostępem) a Lokalnymi Zarządcami Spójności. W ramach protokołu wysyłane są następujące komunikaty: od koordynatora do Lokalnych Zarządców Spójności: Complete informuje Lokalnych Zarządców Spójności o rozpoczętej procedurze zatwierdzania transakcji i oczekiwaniu na głosy Lokalnych Zarządców Spójności za zatwierdzeniem usługi. Zatwierdzanie jest kontynuowane tylko, gdy wszystkie głosy są Completed, w przypadku pojedynczego głosu Wait zatwierdzanie jest opóźnione, w przypadku pojedynczego głosu Compensate zatwierdzanie jest anulowane. Close informuje Lokalnych Zarządców Spójności o zakończonej obsłudze koordynowanej transakcji. LocalCompensate wysyłany przez koordynatora do Lokalnych Zarządców Spójności gdy w wyniku głosowania opisanego w omówieniu komunikatu Complete należy wycofać daną transakcję. Komunikat jest wysyłany tylko do tych Lokalnych Zarządców Spójności, którzy głosowali Completed lub Wait i nie głosowali Compensate. Rollback informuje Lokalnych Zarządców Spójności o fakcie wycofania koordynowanej transakcji, wymuszając modyfikację lokalnych grafów konfliktowej uszeregowalności. Jeśli w wyniku aktualizacji zostanie naruszona spójność grafu konfliktowej uszeregowalności wysyłany jest komunikat Compensate do koordynatorów odpowiednich transakcji. Odpowiedzią na komunikat Rollback jest komunikat Aborted. Przez naruszenie spójności grafu konfliktowej uszeregowalności rozumie się, usunięcie z grafu węzła, który poprzedzał inne węzły, w takiej sytuacji konieczne jest usunięcie poprzedzanych węzłów i tym samym wycofanie reprezentowanych przez te węzły transakcji poprzedzanych. SavepointRollback - nakazuje Lokalnym Zarządcom Spójności modyfikację lokalnych grafów konfliktowej uszeregowalności, która uwzględni fakt częściowej kompensacji transakcji. od Lokalnego Zarządcy Spójności do koordynatora: Completed wysyłany wówczas gdy LZS głosuje za zatwierdzeniem transakcji. Closed komunikat potwierdza zakończenie obsługi transakcji po stronie LZS, Wait wysyłany wówczas gdy LZS głosuje za opóźnieniem zatwierdzania transakcji. Sytuacja ta występuje, gdy zatwierdzana transakcja jest poprzedzana w grafie konfliktowej uszeregowalności przez wciąż aktywną transakcję. Istnieje wówczas konieczność oczekiwania

16 32 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy na zakończenie aktywnej transakcji poprzedzającej. W zależności od sposobu jej zakończenia określany jest sposób zakończenia transakcji koordynowanej. Compensate wysyłany wówczas gdy LZS głosuje za wycofaniem transakcji. Komunikat Compensate jest wysyłany gdy: podczas oczekiwania na zakończenie innej transakcji (patrz komunikat Wait) upłynie określony timeout, lub też gdy dana transakcja ma zostać wycofana np. ze względu na naruszenie spójności grafu konfliktowej uszeregowalności w wyniku wycofywania innej transakcji. Aborted komunikat jest potwierdzeniem wycofania transakcji. SavepointAborted potwierdzenie częściowego wycofania transakcji. Rysunek 10. przedstawia diagram stanów protokołu ConcurrentAccessControlProtocol. Wykorzystanie MZWD dało możliwość poprawnej realizacji współbieżnie wykonywanych procesów biznesowych, która uwzględnia konfliktowość biznesową poszczególnych usług. Należy zaznaczyć, że zastosowane podejście optymistyczne nie zapewnia transakcjom własności izolacji Moduł Konstrukcji Transakcji Koordynator Transakcji posiadający budowę modułową wykorzystuje dwa moduły pełniące z punktu widzenia specyfikacji WS-Coordination rolę koordynatorów MAT oraz MZWD. Obydwa moduły koordynują te same transakcje. Każdy z nich ma swój jasno określony cel. MAT zapewnia spełnienie deklarowanych cech poszczególnych transakcji (obligatoryjności, zależności), dokonuje kompensacji transakcji podczas wycofywania, a także współpracuje z uczestnikami aktywności podczas zatwierdzania transakcji. MZWD zapewnia spójność realizacji dla współbieżnie wykonywanych transakcji. Każdy ze wspomnianych modułów może funkcjonować osobno, zapewniając odpowiednie dla siebie własności. Jednak w sytuacji gdy oba moduły funkcjonują w ramach jednego środowiska Koordynatora Transakcji konieczna jest ich współpraca. Wszystkie komunikaty inicjujące kolejne etapy przetwarzania transakcji wysyłane są przez Moduł Konstrukcji Transakcji (funkcjonujący w ramach Modułu Zarządcy Transakcji), w ramach protokołów EnhancedCompletion lub TransactionFinalizationProtocol, który interpretuje rozszerzenia języka BPEL występujące w Pliku Definicji Transakcji i zamienia je na odpowiednie akcje. Moduł Konstrukcji Transakcji jest uczestnikiem aktywności (w imieniu MZT) zarówno dla MAT jak i MZWD. W naturalny zatem sposób współpraca pomiędzy modułami koordynatorów odbywa się za jego pośrednictwem. Rozwiązanie to jest o tyle uzasadnione, że to Moduł Konstrukcji Transakcji na podstawie definicji transakcji wie, jakie mechanizmy koordynacji w poszczególnych przypadkach są potrzebne. Moduł Konstrukcji Transakcji odpowiedzialny jest za przetwarzania czterech instrukcji sterujących transakcjami (rozszerzeń języka BPEL) begintransaction, commit, rollback, savepoint, które mogą być zapisane w definicji procesów biznesowych (Pliku Definicji Transakcji). Sposób obsługi tych instrukcji w sytuacji gdy oba moduły koordynacji są wykorzystywane opisano poniżej Rozpoczęcie transakcji instrukcja begintransaction W przypadku wystąpienia instrukcji begintransaction Moduł Konstrukcji Transakcji podejmuje kolejno następujące akcje. 1. Aktywacja instancji koordynatora MAT oraz odbiór adresu rejestracji i kontekstu koordynacji, który będzie przekazywany w nagłówkach komunikatów wysyłanych do usług. 2. Aktywacja instancji koordynatora MZWD oraz odbiór adresu rejestracji i kontekstu koordynacji, który będzie przekazywany w nagłówkach komunikatów wysyłanych do usług.

17 Koordynowanie procesów biznesowych w środowiskach SOA Rejestracja (pod adresem uzyskanym w punkcie 1.) w koordynatorze MAT jako uczestnika protokołu EnhancedCompletion oraz odbiór adresu koordynatora MAT. 4. Rejestracja (pod adresem uzyskanym w punkcie 2.) w koordynatorze MZWD jako uczestnika protokołu TransactionFinalizationProtocol oraz odbiór adresu koordynatora MZWD Zatwierdzenie transakcji instrukcja commit W przypadku wystąpienia instrukcji commit Moduł Konstrukcji Transakcji podejmuje kolejno następujące akcje. 1. Wysłanie komunikatu complete do koordynatora MZWD, oczekiwanie na odpowiedź koordynatora. 2. W zależności od rodzaju odpowiedzi od koordynatora MZWD: (a) w przypadku otrzymania komunikatu compensate: i. do koordynatora MAT wysyłany jest komunikat rollback, ii. odbiór komunikatu aborted od koordynatora MAT, iii. koniec obsługi instrukcji commit, (b) w przypadku otrzymania komunikatu completed i. przejście do punktu Wysłanie komunikatu commit do koordynatora MAT, oczekiwanie na odpowiedź koordynatora. 4. W zależności od rodzaju odpowiedzi od koordynatora MAT: (a) w przypadku otrzymania komunikatu aborted: i. do koordynatora MZWD wysyłany jest komunikat rollback, ii. odbiór komunikatu aborted od koordynatora MZWD, iii. koniec obsługi instrukcji commit, (b) w przypadku otrzymania komunikatu committed i. przejście do punktu Wysłanie komunikatu close do koordynatora MZWD, oczekiwanie na odpowiedź koordynatora. 6. Otrzymanie komunikatu closed od koordynatora MZWD Wycofywanie pełne transakcji instrukcja rollback bez wskazanego punktu zachowania W przypadku wystąpienia instrukcji rollback bez wskazanego punktu zachowania Moduł Konstrukcji Transakcji podejmuje kolejno następujące akcje. 1. Wysłanie komunikatu rollback do koordynatora MAT, oczekiwanie na odpowiedź koordynatora. 2. Otrzymanie komunikatu aborted od koordynatora MAT. 3. Wysłanie komunikatu rollback do koordynatora MZWD, oczekiwanie na odpowiedź koordynatora. 4. Otrzymanie komunikatu aborted od koordynatora MZWD Tworzenie punktu zachowania instrukcja savepoint W przypadku wystąpienia instrukcji savepoint Moduł Konstrukcji Transakcji podejmuje kolejno następujące akcje.

18 34 Krzysztof Jankiewicz, Mateusz Mor, Kamil Kujawiński, Tadeusz Morzy 1. Wysłanie komunikatu savepoint do koordynatora MAT z informacją o numerze operacji oraz nazwie punktu zachowania. 2. Wysłanie komunikatu savepoint od koordynatora MZWD z informacją o numerze operacji oraz nazwie punktu zachowania Wycofywanie do punktu zachowania instrukcja rollback ze wskazanym punktem zachowania W przypadku wystąpienia instrukcji rollback ze wskazanym punktem zachowania Moduł Konstrukcji Transakcji podejmuje kolejno następujące akcje. 1. Wysłanie komunikatu savepointrollback do koordynatora MAT z nazwą punktu zachowania, oczekiwanie na odpowiedź koordynatora. 2. Otrzymanie komunikatu savepointaborted od koordynatora MAT. 3. Wysłanie komunikatu savepointrollback do koordynatora MZWD z nazwą punktu zachowania, oczekiwanie na odpowiedź koordynatora. 4. Otrzymanie komunikatu savepointaborted od koordynatora MZWD. 5. Oracle BPEL Process Manager jako Moduł Zarządcy Transakcji Koordynator Transakcji ma budowę modułową, która jest na tyle elastyczna, że może być dopasowana do różnych konfiguracji systemów przetwarzających procesy biznesowe. W szczególności można sobie wyobrazić funkcjonowanie Koordynatora Transakcji opartego o różne serwery procesów biznesowych. Serwer procesów biznesowych w ramach Koordynatora Transakcji pełni rolę Modułu Zarządcy Transakcji. W pierwotnej konfiguracji w tym celu wykorzystany został serwer Apache ODE w wersji 2.0, w którym można wykorzystać rozszerzenia definicji procesów BPEL mające postać własnych konstrukcji umieszczonych w znacznikach <bpel:extensionactivity>. Aby udowodnić tezę o elastyczności przyjętego przez nas rozwiązania postanowiliśmy dokonać jego implementacji w oparciu o Oracle BPEL Process Manager Wymagania Aby była możliwość implementacji Modułu Zarządcy Transakcji w ramach serwera procesów BPEL konieczne jest spełnienie przez niego kilku warunków: Mechanizmy Modułu Konstrukcji Transakcji zostały zaimplementowane przy wykorzystaniu języka Java. Implementacja każdego z rozszerzeń wymienionych w punktach 4.1 oraz 4.5 zrealizowana została za pomocą oddzielnej klasy Javy. Aby możliwe było odpowiednie wykorzystanie Modułu Konstrukcji Transakcji w ramach serwera procesów BPEL muszą istnieć konstrukcje, które w trakcie przetwarzania procesu BPEL pozwolą korzystać z zewnętrznych klas Javy. Mechanizmy Modułu Konstrukcji Transakcji, rozszerzające funkcjonalność serwera procesów BPEL muszą mieć możliwość wykorzystywania zmiennych środowiska BPEL, definiowanych w ramach procesu biznesowego. Zmienne te wykorzystywane są do przechowywania niezbędnych podczas koordynacji, a także do wymiany tej informacji pomiędzy kolejnymi akcjami Modułu Konstrukcji Transakcji podejmowanymi na rzecz tych samych transakcji. Ze względu na fakt iż Modułem Zarządcy Transakcji nie zawsze jest stroną inicjującą pewne zdarzenia i musi również reagować na komunikaty zewnętrzne wysyłane od modułów