Kompensowalność w procesach biznesowych

Transkrypt

1 XVII Konferencja PLOUG Kościelisko Październik 2011 Kompensowalność w procesach biznesowych Hubert Gęzikiewicz, Krzysztof Jankiewicz, Tadeusz Morzy Politechnika Poznańska, Instytut Informatyki e mail: Krzysztof.Jankiewicz@cs.put.poznan.pl Abstrakt. Przypadki, w których proces biznesowy przetwarzany w środowisku SOA nie może w pełni zrealizować swojego przetwarzania, bardzo często prowadzą do konieczności podjęcia kompensacji tych aktywności, które do momentu decyzji o anulowaniu procesu zostały wykonane. Podejście to jest szeroko rozpowszechnione wśród standardów związanych z przetwarzaniem procesów biznesowych w środowiskach SOA. Opierają się na nim specyfikacje koordynacji procesów, języki wykonawcze dla procesów biznesowych, a także notacje używane do projektowania procesów. Niestety żadna ze specyfikacji nie dostarcza mechanizmów, które zabezpieczałyby możliwość dokonania kompensacji. Brak takich mechanizmów może prowadzić do sytuacji, które w standardzie BPMN określane są jako hazardowe. Dochodzi do nich wówczas, gdy proces, którego wykonanie nie może zostać zakończone, nie może zostać także w pełni skompensowany. Jego wynik jest wówczas nieokreślony, niezgodny z zamierzeniami projektanta procesu, może prowadzić do niespójności. Przypadki te wymuszają często konieczność ręcznego rozwiązania zaistniałej, niekorzystnej, sytuacji. Niniejszy artykuł skupia się na powyższym problemie, dokonuje jego analizy a także proponuje sposób jego rozwiązania. 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,

2

3 Kompensowalność w procesach biznesowych Wstęp Większość standardów związanych z przetwarzaniem długotrwałych procesów biznesowych uwzględnia konieczność wykorzystania mechanizmów kompensacji. Mechanizmy te mają na celu odwrócenie efektów działań zrealizowanych w ramach procesu do czasu, w którym została podjęta decyzja o jego anulowaniu, a które to działania nie mogą być po prostu wycofane. Niestety w środowisku, w którym procesy biznesowe przetwarzane są współbieżnie przy jednoczesnym braku izolacji może dochodzić do sytuacji, w których możliwość wykonania kompensacji dla zakończonych wcześniej aktywności będzie niemożliwa. Może to grozić utratą spójności a także wymagać ręcznego rozwiązywania zaistniałych problemów. Wyeliminowanie takich przypadków, lub choćby ich ograniczenie ma istotne znaczenie dla aplikacji klasy business-to-business (B2B) czy też business-to-customer (B2C) funkcjonujących w środowisku SOA. Niniejszy artykuł proponuje rozwiązanie tego problemu, które uwzględnia obecnie funkcjonujące specyfikacje i standardy związane z koordynacją procesów biznesowych w środowisku SOA. W rozdziale 2, przeanalizowane zostało podejście do kompensacji jakie reprezentują obowiązujące standardy i specyfikacji. W rozdziale 3 przedstawiony został przyjęty przez nas model procesu biznesowego, który uwzględnia wspomniane standardy. W oparciu o ten model, w rozdziale 4 scharakteryzowany został problem zapewnienia możliwości kompensacji -- kompensowalności. Rozdział 5 przedstawia propozycję rozwiązania problemu kompensowalności. Na zakończenie w rozdziale 6 przedstawione zostały wyniki przeprowadzonych eksperymentów. 2. Kompensacja a standardy Podejście do kompensacji różni się w zależności od standardu. Część ze specyfikacji jak np. WS-BA [FrLi09] zakłada, że to usługa wykorzystywana podczas procesu biznesowego jest odpowiedzialna za czynności kompensacyjne wykonanych przez nią działań. Wywołanie tych czynności jest uruchamiane, w przypadku tej specyfikacji, za pomocą prostego komunikatu wysyłanego do usługi. Aplikacja, która przetwarza proces nie posiada wiedzy dotyczącej tego w jaki sposób dokonywana jest kompensacja, nie ma też na jej postać żadnego wpływu. Takie podejście przypomina w pewnym sensie systemowe wycofanie transakcji, którego sposób realizacji znajduje się poza samą definicją transakcji. Zupełnie odmienne rozwiązanie przyjęte zostało w przypadku języka definicji procesów biznesowych WS-BPEL [AAA09]. Działania kompensacyjne są, w tym przypadku, fragmentem definicji procesu. Za ich wykonanie i sposób realizacji odpowiedzialna jest aplikacja. W najnowszej wersji specyfikacji BPMN [BPMN20], służącej do modelowania procesów biznesowych, zaproponowano jeszcze inne rozwiązanie. Z jednej strony projektant procesu biznesowego ma możliwość deklarowania określonych aktywności kompensacyjnych dla każdej z aktywności podejmowanych w ramach procesu. Z drugiej jednak strony, może on na poziomie tzw. podprocesów transakcyjnych deklarować tzw. typ koordynacji (np. zgodny ze specyfikacją WS-BA) jaki ma być wykorzystany podczas wykonywania podprocesu. Można powiedzieć zatem, że specyfikacja BPMN próbuje połączyć oba podejścia do kompensacji -- systemowe, w którym wiedza na temat kompensacji leży po stronie usług, a uruchamianie kompensacji odbywa się za pomocą mechanizmów koordynacji, oraz proceduralne, w którym wiedza dotycząca kompensacji poszczególnych fragmentów procesu zawarta jest w jego definicji. Uwzględnienie obu podejść w specyfikacji BPMN jest silnym sygnałem, że oba rozwiązania w procesach biznesowych powinny być uwzględniane. Ponadto, jest to potwierdzenie faktu, że przetwarzanie procesów biznesowych, o ile mają one posiadać pewne własności, nie może być oparte tylko i wyłącznie na prostym wykonywaniu zawartych w nich definicji, wymaga to (w szczególności dla tzw. podprocesów transakcyjnych) wykorzystania wspomagających mechanizmów koordynacji.

4 42 Hubert Gęzikiewicz, Krzysztof Jankiewicz, Tadeusz Morzy 3. Model procesu biznesowego W dalszych rozważaniach przyjmujemy następujący model procesu biznesowego. Należy podkreślić, że model ten jest spójny z każdą z powyższych specyfikacji, co czyni prezentowane w tym artykule rozwiązanie uniwersalnym. Proces biznesowy PB składa się z aktywności.,,, ; Α gdzie Α jest zbiorem wszystkich aktywności. Z aktywnością może być związana aktywność kompensacyjna. Dla takiego przypadku przyjmujemy następujące oznaczenie Wyrażeniem Α będziemy oznaczali zbiór aktywności posiadających aktywność kompensacyjną, podczas gdy zbiór aktywności, które nie posiadają przypisanej aktywności kompensacyjnej będziemy oznaczali jako Α. Dla takich aktywności spełnione są następujące zależności: Α Α Α Ponadto spełnione jest także: Α Α Α Α, Α Α, Warto zwrócić uwagę, że aktywność kompensacyjna nie może posiadać własnych aktywności kompensacyjnych, gdyż należy ona do zbioru aktywności Α N. Każda aktywność Α może być akcją, podprocesem lub po prostu zbiorem aktywności,,, ; Α Przez akcję a i rozumiemy najmniejszą, niepodzielną, jednostkę procesu biznesowego. Specyficznym przykładem akcji może być wywołanie usługi składowej procesu. Podproces składa się z aktywności,,, ; Α Zakładamy, że podproces może posiadać zadeklarowane własności, których zapewnienie wymaga wykorzystania mechanizmów koordynacji wykraczających poza definicje aktywności podprocesu. Mówimy wówczas, podobnie jak to jest w przypadku standardu BPMN o podprocesach transakcyjnych. Podproces transakcyjny może zakończyć się zatwierdzeniem lub anulowaniem. W przypadku anulowania podprocesu transakcyjnego pt i wymagane jest wykonanie wszystkich aktywności kompensacyjnych takich, że ; Α. Zakładamy istnienie następujących własności dostarczanych podprocesom transakcyjnym przez mechanizmy koordynacji: obligatoryjności/opcjonalności (determinuje wpływ jaki ma fiasko podprocesu transakcyjnego na wynik nadrzędnego podprocesu transakcyjnego), zależności/niezależności (determinuje sposób reakcji podprocesu transakcyjnego na fiasko nadrzędnego podprocesu transakcyjnego) i kompensowalności (zabezpiecza możliwość kompensacji dla wszystkich aktywności wchodzących w skład podprocesu transakcyjnego). Zadaniem dwóch pierwszych własności jest uproszczenie definicji procesów biznesowych, przeniesienie części implementacji na rozwiązania systemowe - mechanizmy koordynacji. Rozważania na temat tych własności były tematem referatu prezentowanego na konferencji PLOUG w roku ubiegłym [JMKM10]. Tym razem tematem jest kompensowalność.

5 Kompensowalność w procesach biznesowych Kompensowalność Trzecią z własności, które mogą być wymagane przez podproces transakcyjny jest własność kompensowalności. Jak to zostało już wcześniej wspomniane, anulowanie podprocesu transakcyjnego determinuje konieczność kompensacji wszystkich aktywności Α, które są składowymi podprocesu transakcyjnego i które zostały zakończone do momentu podjęcia decyzji o jego anulowaniu. Sytuacja, w której tylko część takich aktywności zostanie skompensowana, może być przyczyną niespójnego przetwarzania i w związku z tym jest wysoce niepożądana. Własność kompensowalności ma na celu wyeliminowanie takich przypadków, które w ramach standardu określane są jako hazardowe. Powszechnie uznaje się, że podstawowym i najczęstszym zadaniem kompensacji takiej, że jest wykonanie działań w pełni lub częściowo odwracających efekty aktywności. Można zatem założyć, że aktywność przygotowuje możliwość dokonania kompensacji i w przy- padku izolowanego przetwarzania zagrożenie dla kompensacji nie występuje. Niestety założenie, że przetwarzanie procesów biznesowych w środowiskach SOA będzie realizowane w sposób izolowany nie jest z reguły ani możliwe ani pożądane [MSJL06, KBS2004]. W związku z tym, uwzględniając współbieżne wykonywanie procesów biznesowych przy braku izolacji przetwarzania, musimy przyjąć, że zagrożenia aktywności kompensacyjnych będą miały miejsce. Aby wyjaśnić ten problem rozważmy następujący przykład. Załóżmy, że celem podprocesu transakcyjnego jest dokonanie wymiany zarezerwowanego uprzednio pokoju hotelowego. W tym celu w ramach podprocesu transakcyjnego zdefiniowano dwie aktywności: anulowania rezerwacji pokoju X, oraz dokonania rezerwacji pokoju Y. Obie aktywności wykonywane są za pomocą wywołania odpowiednich usług sieciowych. Załóżmy, że każda z tych aktywności ma określoną aktywność kompensacyjną. I tak, dla aktywności aktywnością kompensacyjną będzie ponowna rezerwacja zwolnionego pokoju, a dla aktywności aktywnością kompensacyjną będzie aktywność anulowania dokonanej rezerwacji. Każda z wykorzystywanych usług działa w sposób, który bezpośrednio po jej wywołaniu udostępnia efekty na zewnątrz. Załóżmy, że po wykonaniu aktywności, współbieżnie wykonywany podproces dokonał rezerwacji pokoju zarówno zwolnionego pokoju X jak i dodatkowego pokoju Y, a następnie zakończył swoje działanie. W efekcie aktywność nie mogła zostać wykonana ze względu na zajętość pokoju Y. Z tego powodu podproces transakcyjny podejmuje decyzję o anulowaniu. Niestety pełne anulowanie nie jest możliwe -- kompensacja nie może zostać wykonana ze względu na rezerwację pokoju X przez proces. Z przykładu powyżej wynika, że zapewnienie kompensowalności wymaga dodatkowych mechanizmów, wykraczających poza definicję podprocesu transakcyjnego, uwzględniających działania wykonywane przez współbieżnie przetwarzane procesy. 5. Zapewnienie własności kompensowalności 5.1. Podproces jako kontrakt Aby zapewnić własność kompensowalności odpowiedzialne za to mechanizmy koordynacji powinny przetwarzać podproces transakcyjny jako pewnego rodzaju kontrakt. Strony tego kontraktu to, po pierwsze aplikacja, która przetwarza podproces, a po drugie wszyscy uczestnicy podprocesu (np. usługodawcy), którzy są odpowiedzialni za aktywności kompensacyjne. Jak wspomniano we wcześniejszych rozdziałach, źródło informacji dotyczącej aktywności kompensacyjnych może być różne. Z jednej strony wiedza o aktywnościach kompensacyjnych może należeć do definicji procesu w takim przypadku są one przyporządkowywane albo prostej aktywności, która może być akcją podstawową (np. pojedyncze wywołanie usługi) albo złożonej aktywności (np. scope w definicji procesu wyrażonej w języku BPEL) składającej się z wielu aktywności podrzędnych. Z drugiej

6 44 Hubert Gęzikiewicz, Krzysztof Jankiewicz, Tadeusz Morzy strony wiedza ta może być zaszyta w implementacji poszczególnych usług wykorzystywanych w ramach procesu, znajdujących po stronie dostawców usług i być przykładowo uruchamiana tak jak ma to miejsce w przypadku specyfikacji WS-BA za pomocą komunikatów przesyłanych do usług. Niezależnie od pochodzenia tej informacji i od sposobu uruchamiania kompensacji, można w sposób jednoznaczny przyporządkować pojedynczą aktywność kompensacyjną do określonej aktywności. Jest to zgodne ze wszystkimi omówionymi wcześniej specyfikacjami i standardami. Zadaniem mechanizmów odpowiedzialnych za zapewnienie własności kompensowalności byłoby doprowadzenie do sytuacji, w której aktywność Α byłaby wykonywana jedynie w przypadku, gdy zapewniona byłaby możliwość wykonania aktywności takiej, że. Stroną uprawnioną do udzielania deklaracji takich możliwości są szeroko rozumiani usługodawcy udostępniający aktywności kompensacyjne i za nie odpowiedzialni. Udzielenie takich deklaracji powinno być warunkiem koniecznym do rozpoczęcia aktywności. Brak deklaracji (ze względu na brak możliwości zagwarantowania wykonania akcji kompensacyjnych) powinien prowadzić albo do wstrzymania rozpoczęcia aktywności (do czasu ustąpienia przyczyn uniemożliwiających udzielenia deklaracji), lub też do anulowania podprocesu transakcyjnego takiego, że. Strona, która winna żądać takich deklaracji jest zależna od tego gdzie informacja dotycząca kompensacji jest dostępna. W zależności od tego czy kompensacja wynika z deklaracji na poziomie definicji procesu czy też jest zawarta w implementacji usługi składowej, stroną żądającą powinna być aplikacja, która ten podproces transakcyjny przetwarza lub usługa składowa. W dalszej części artykułu deklarację możliwości wykonania aktywności kompensacyjnej będziemy oznaczali przez. Wywołanie aktywności kompensacyjnej takiej, że, może mieć miejsce tylko dla takich aktywności, które zostały wykonane i zakończone. W związku z powyższym, mechanizmy koordynacji odpowiedzialne za własność kompensowalności powinny dawać możliwość zwolnienia usługodawcy aktywności kompensacyjnej z w przypadku, gdy aktywność zostanie przerwana i anulowana. Niezależnie od tego, jaka strona żąda, są one uzyskiwane zawsze na rzecz przetwarzanej instancji podprocesu transakcyjnego takiego że. Jest to o tyle istotne, że deklaracje te muszą być utrzymywane aż do chwili zakończenia podprocesu transakcyjnego. Zakończenie przetwarzania instancji podprocesu transakcyjnego wiąże się z rozwiązaniem kontraktu i w związku z tym ze zwolnieniem usługodawców odpowiedzialnych za aktywności kompensacyjne z konieczności dalszego zapewniania możliwości ich wykorzystania. Podsumowując, przetwarzanie aktywności Α powinno być realizowane w następujący sposób: 1. Przed rozpoczęciem aktywności wysyłane jest żądanie udzielenia, gdzie, do usługodawcy aktywności. 2. Po otrzymaniu aktywność może zostać rozpoczęta. 3. W przypadku przerwania aktywności i jej anulowania do usługodawcy aktywności wysyłane jest zwolnienie z udzielonej. 4. W przypadku zatwierdzenia lub wycofania podprocesu transakcyjnego takiego, że do usługodawcy aktywności wysyłana jest informacja dotycząca zakończenia podprocesu transkacyjnego Rola usługodawcy aktywności kompensacyjnej Zadaniem usługodawcy aktywności kompensacyjnej jest nie tylko ocena możliwości jej wykonania i udzielenie, ale także zabezpieczenie wspomnianej możliwości wykonania aktywności kompensacyjnej przez cały czas trwania podprocesu transakcyjnego, który wykorzystuje aktywność taką że.

7 Kompensowalność w procesach biznesowych 45 W rozdziale 4 zostało wspomniane, że podstawowym zagrożeniem dla aktywności kompensacyjnych jest brak izolacji przetwarzania i współbieżnie wykonywane procesy korzystające z aktywności, których wykonanie może uniemożliwić późniejsze wywiązanie się z udzielonych. Wynika z tego, że usługodawca powinien monitorować realizację wszystkich aktywności, które mogą uniemożliwić póżniejsze wykonanie aktywności kompensacyjnej i mieć na ich realizację wpływ. Na marginesie należy zaznaczyć, że ocena tego czy aktywność jest zagrożeniem dla aktywności kompensacyjnej jest zagadnieniem odrębnym, które może być przykładowo związane z konfliktami semantycznymi [LRD08], i wykracza ono poza ramy tego artykułu. Postępowanie usługodawcy, który otrzyma żądanie wykonania aktywności zagrażającej aktywności kompensacyjnej może być bardzo różne. W najprostszym przypadku może on wstrzymać wykonanie aktywności aż do momentu zakończenia podprocesu do którego aktywność należy. Jednak w przypadku, w którym mamy do czynienia z długotrwałymi procesami biznesowymi oraz autonomicznymi aktywnościami udostępnianymi przez różnych usługodawców, wymagane jest zastosowanie innych rozwiązań. Większość autorów prac poruszających kwestie dotyczące mechanizmów kontroli współbieżnej realizacji procesów biznesowych w środowisku SOA [ADV06, KBS2004, MSJL06] uważa, że właściwym rozwiązaniem byłoby podejście optymistyczne, polegające na koordynacji etapu zatwierdzania podprocesów transakcyjnych, w którym blokady byłyby w znaczący sposób ograniczone lub wyeliminowane. Przy zastosowaniu podejścia optymistycznego może zostać uwzględniony fakt, że aktywność, która wprowadza zagrożenie dla aktywności kompensacyjnej może należeć do zbioru Α. W takim przypadku postać aktywności kompensacyjnej może być wykorzystana przez usługodawcę do wyboru odpowiedniej reakcji na żądanie wykonania aktywności. Aby rozważyć to zagadnienie powróćmy do przykładu z rozdziału 4. Załóżmy, że równolegle wykonywany podproces dokonał rezerwacji pokoju X za pomocą aktywności, której aktywnością kompensacyjną byłaby aktywność polegająca na zwolnieniu rezerwacji pokoju X. Wykonanie aktywności wprowadza zagrożenie kompensowalności dla podprocesu transakcyjnego, jednak dopóki podproces będzie aktywny, dopóty istnieje możliwość wyeliminowania tego zagrożenia za pomocą anulowania podprocesu i kompensacji jego aktywności. Uwzględniając powyższe rozważania możemy mówić o dwóch rodzajach zagrożeń dla aktywności kompensacyjnych względnych oraz bezwzględnych. Jeżeli aktywność wprowadzająca zagrożenie dla aktywności kompensacyjnej posiada aktywność kompensacyjną, która to zagrożenie niweluje, to mówimy o względnym zagrożeniu kompensowalności. Przykładem aktywności wprowadzających zagrożenia względne byłyby aktywności posiadające aktywności kompensacyjne, które dokonują pełnej kompensacji. Jeżeli aktywność wprowadzająca zagrożenie dla aktywności kompensacyjnej, posiada aktywność kompensacyjną, która wprowadzonego zagrożenia nie eliminuje, lub też nie posiada aktywności kompensacyjnej ewentualnie gdy aktywność kompensacyjna (lub jej skutki) nie jest znana, wówczas mówimy o bezwzględnym zagrożeniu kompensowalności. W przypadku gdy usługodawca otrzymuje żądanie wykonania aktywności wprowadzającej względne zagrożenie kompensowalności podprocesu może podjąć realizację aktywności pod warunkiem, że mechanizmy koordynacji pozwalają mu na kontrolę procesu zatwierdzenia podprocesu. Wykonanie aktywności w takim przypadku doprowadza do uzależnienia zatwierdzenia podprocesu od zatwierdzenia podprocesu. Podproces staje się w takim przypadku dla podprocesu podprocesem poprzedzającym. Anulowanie podprocesu wymusza uprzednie anulowanie podprocesu, natomiast zatwierdzenie podprocesu jest warunkiem koniecznym do zatwierdzenia podprocesu.

8 46 Hubert Gęzikiewicz, Krzysztof Jankiewicz, Tadeusz Morzy Podsumowując, żądanie wykonania aktywności należącej do podprocesu przez usługodawcę tej aktywności powinno być obsługiwane w następujący sposób: 1. Sprawdzane jest czy aktywność wprowadza zagrożenie kompensowalności dla dowolnego aktywnego podprocesu, dla którego istnieją aktywne gdzie. 2. Jeśli zagrożenia kompensowalności nie występują, wówczas aktywność może zostać wykonana. 3. Jeżeli istnieją aktywne podprocesy, dla których aktywność wprowadza zagrożenie kompensowalności, wówczas dla każdego z podprocesów dokonywana jest ocena czy jest to zagrożenie względne czy bezwzględne. 4. Jeżeli istnieje choć jeden podproces dla którego zagrożenie jest bezwględne wówczas wykonanie aktywności zostaje wstrzymane aż do momentu zakończenia podprocesu. 5. Jeżeli istniejące zagrożenia są jedynie względne dla podprocesów wówczas aktywność może zostać wykonana. Każdy z podprocesów staje się wówczas podprocesem poprzedzającym dla podprocesu. Przyjęte rozwiązanie wymaga, na etapie zatwierdzania (oraz anulowania) podprocesu, współpracy usługodawców wszystkich aktywności, które w ramach podprocesu miały miejsce ze stroną przetwarzającą podproces. Wynika to z faktu iż wykonywanie aktywności wprowadzające zagrożenia względne może prowadzić do sytuacji, w której podproces będzie posiadał szereg podprocesów poprzedzających, od których będzie on zależny. Współpraca może zostać zrealizowana w oparciu o algorytm 2PC, w którym w pierwszej fazie uzyskiwane są potwierdzenia od usługodawców informujące, że podproces nie posiada już żadnych podprocesów poprzedzających i może zostać zatwierdzony, natomiast w drugiej fazie wysyłane są potwierdzenia do usługodawców o fakcie zakończenia podprocesu. 6. Przeprowadzone testy i ich wyniki Mechanizmy zapewniających kompensowalność podprocesów transakcyjnych zostały przez nas zaimplementowane zgodnie z regułami specyfikacji WS-Coordination [FeJe09] w ramach środowisko BProCORE (Business PROcess CORdination Environment) [JMKM11], które powstało w ramach projektu IT-SOA [ABCGZ10]. Więcej szczegółów na temat środowiska BProCORE można znaleźć na stronie projektu Wpływ tych mechanizmów na przetwarzanie procesów biznesowych został przez nas przebadany w oparciu o szereg różnorodnych testów. W jednym z nich posłużyliśmy się scenariuszem podobnym do opisanego w przykładzie z rozdziału 4. Aplikacja testowa generowała współbieżne sekwencje podprocesów transakcyjnych doprowadzając do sytuacji, w których pojawiało się ryzyko braku kompensowalności. Liczba współbieżnie przetwarzanych sekwencji wahała się przy kolejnych uruchomieniach testu pomiędzy 2 a 14 zmieniając w ten sposób prawdopodobieństwo wystąpienia zależności pomiędzy podprocesami. Każdy z podprocesów transakcyjnych wykorzystywał usługi rezerwacji i zwalniania pokojów hotelowych. Usługi te były dostarczane przez pojedynczego usługodawcę reprezentującego pojedynczy hotel. Liczba pokojów, którymi dysponowały usługi rezerwacji i zwalniania rezerwacji wahała się w przedziale W związku z tym, że rezerwacje lub zwolnienia dotyczące tego samego pokoju hotelowego były pomiędzy sobą w konflikcie, zmiana liczby pokojów symulowała zmienny poziom konfliktowości usług. Zadaniem każdego z podprocesów transakcyjnych, podobnie jak we wspomnianym przykładzie, była zamiana zarezerwowanych pokojów. Aby symulować procesy transakcyjne o różnej długości trwania, dokonywały one różnej liczby zamiany pokojów w przedziale od 1 do 4.

9 Kompensowalność w procesach biznesowych 47 Rys. 1. Liczba hazardowych podprocesów przy zmieniającym się poziomie konfliktów Testy przeprowadziliśmy dla trzech różnych konfiguracji środowiska. W pierwszej z nich, oznaczonej na wykresach jako none, nie wykorzystywaliśmy w przypadku podprocesów transakcyjnych, żadnych mechanizmów koordynacji. W drugiej konfiguracji, oznaczonej na wykresach jako pesimistic, zastosowanym mechanizmem był klasyczny 2PL (ang: two-phase locking protocol), w którym każda aktywność wprowadzająca zagrożenie kompensowalności dla podprocesu transakcyjnego była blokowana aż do chwili gdy podproces transakcyjny się zakończył. W trzeciej konfiguracji, oznaczonej na wykresach jako optimistic, zastosowany został opracowany przez nas mechanizm opierający się na podejściu optymistycznym. Uzyskane wyniki zostały przedstawione na wykresach. Rys. 2. Liczba hazardowych podprocesów przy zmieniającej się liczbie współbieżnie wykonywanych sekwencji podprocesów Na rys. 1 przedstawiającym procentową liczbę hazardowych podprocesów przy zmieniającym się poziomie konfliktów, zgodnie z przewidywaniami można zaobserwować, że zmniejszający się poziom konfliktów (zwiększająca się liczba pokojów hotelowych) powodował zmniejszanie się liczby podprocesów transakcyjnych, które kończyły się w sposób hazardowy. Należy zauważyć, że zastosowane przez nas podejście znacząco wpłynęło na zmniejszenie się tej liczby w porównaniu do konfiguracji bez mechanizmów koordynacji.

10 48 Hubert Gęzikiewicz, Krzysztof Jankiewicz, Tadeusz Morzy Rys. 3. Liczba skompensowanych podprocesów przy zmieniającej się liczbie współbieżnie wykonywanych sekwencji podprocesów Na rys. 2 przedstawiającym liczbę hazardowych podprocesów przy zmieniającej się liczbie współbieżnie wykonywanych sekwencji podprocesów można zaobserwować, że w przypadku braku mechanizmu koordynacji liczba hazardowych podprocesów rosła w sytuacji gdy wzrastała liczba współbieżnie wykonywanych sekwencji podprocesów transakcyjnych. Interesujące jest to, że w przypadku zastosowania opracowanych przez nas mechanizmów wzrost liczby współbieżnie wykonywanych sekwencji nie miał wpływu na procentowo wyrażoną liczbę podprocesów hazardowych. Oczywistą konsekwencją proponowanych mechanizmów koordynacji jest wzrost liczby podprocesów transakcyjnych kończących się kompensacją. Wynika to z faktu wprowadzania zależności pomiędzy podprocesami. Ilustruje to rys. 3. Na ostatnim rys. 4 można zaobserwować jeszcze jeden fakt, który również jest zgodny z podstawami teoretycznymi. Rysunek ten przedstawia względny czas pojedynczego wywołania usługi przy zmieniającej się długości podprocesu. Czas ten został wyznaczony przez podzielenie całkowitego czasu trwania testu przez liczbę wywołań usług wchodzących w skład zatwierdzonych (czyli decydujących o wydajności) podprocesów transakcyjnych. To co można zaobserwować to fakt, iż przy mniejszej poziomie konfliktów (krótkie podprocesy) podejście optymistyczne jest wydajniejsze niż podejście pesymistyczne. Jednak gdy poziom konfliktów wzrasta podejście pesymistyczne zdaje się uzyskiwać przewagę. Rys. 4. Względny czas pojedynczego wywołania usługi przy zmieniającej się długości podprocesu

11 Kompensowalność w procesach biznesowych 49 Mała różnica w wydajności, którą obserwujemy na wykresie, wynika z faktu, iż wykorzystywane przez nas podprocesy transakcyjne trwały bardzo krótko, od kilku do kilkunastu sekund. W przypadku, gdy czas trwania podprocesów uzyskiwałaby rozmiary zgodne z przypadkami obserwowanymi w przemyśle, różnica ta byłaby o wiele bardziej znacząca. 7. Podsumowanie i dalsze prace Przeprowadzone eksperymenty wykazały, że wprowadzenie zaprojektowanych i zaimplementowanych przez nas mechanizmów koordynacji w środowiskach, w których kompensowalność może być zagrożona, przyczynia się do znaczącego ograniczenia liczby podprocesów, które kończą się w sposób nieokreślony hazardowy. Jednocześnie należy zaznaczyć, że prace nad mechanizmami zapewniającymi własność kompensowalności będą przez nas kontynuowane. Analizując w szczególności rys. 1 oraz rys. 2 można zauważyć, że zastosowanie klasycznego rozwiązania opartego na protokole 2PL daje pełną gwarancję kompensowalności podprocesów podprocesy hazardowe w ogóle nie występują. Tymczasem zastosowanie proponowanego przez nas rozwiązania niestety pewną liczbę podprocesów hazardowych dopuszcza. Powodem takiego stanu rzeczy jest zastosowane przez nas podejście optymistyczne. Dopuszcza ono do sytuacji, w której podprocesy transakcyjne będą wzajemnie od siebie zależne graf ich wzajemnego poprzedzania będzie tworzył cykl. W przypadku anulowania jednego z takich podprocesów niestety nie istnieje poprawna kolejność ich kompensacji jeden z podprocesów tworzący taki cykl, niestety będzie musiał zakończyć się w sposób nieokreślony. W chwili obecnej trwają prace nad rozwiązaniem tego problemu. Bibliografia [AAA09] Alves A., Arkin A., Askary S., Barreto C, Bloch B., Curbera F., Ford M., Goland Y., Guízar A., Kartha N., Liu C.K., Khalaf R., König D., Marin M., Mehta V., Thatte S., van der Rijn D., Yendluri P., Yiu A.: Web Services Business Process Execution Language, [ABCGZ10] Ambroszkiewicz S., Brzeziński J., Cellary W., Grzech A., Zieliński K. (edytorzy): SOA Infrastructure Tools - Concepts and Methods Poznan University of Economics Press, [ADV06 ] Alrifai M., Dolog P., Vej F.B., Dk-Aalborg, Nejdl W.: Transactions concurrency control in web service environment. In In ECOWS '06: Proceedings of the European Conference on Web Services, strony IEEE, [BPMN20] Business Process Model and Notation (BPMN) version 2.0, [FeJe09] Feingold M., Jeyaraman R.: OASIS Web Services Coordination Version [FrLi09] Freund T., Little M.: OASIS Web Services Business Activity Version 1.2, [JMKM11] Jankiewicz K., Morzy T., Kujawiński K., Mor M.: Transaction mechanisms in complex business processes. Control and Cybernetics, 2011, special issue. [JMKM10] Jankiewicz K., Morzy T., Kujawiński K., Mor M.: Koordynowanie procesów biznesowych w środowiskach SOA. XVI Konferencja użytkowników i deweloperów ORACLE. Systemy informatyczne. Projektowanie, implementowanie, eksploatowanie., 2010, [KBS2004] Krafzig D., Banke K., Slama D.: Enterprise SOA: Service-Oriented Architecture Best Practices. The Coad Series. Prentice Hall, Upper Saddle River, NJ, USA, [LRD08] Ly L.T., Rinderle S., Dadam P.: Integration and verification of semantic constraints in adaptive process management systems Data Knowl. Eng., Elsevier Science Publishers B. V., 2008, 64, [MSJL06] McGovern J., Sims O., Jain A., Little M.: Enterprise Service Oriented Architectures: Concepts, Challenges, Recommendations. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2006.