Obsªuga bª dów w procesach automatycznej konsolidacji rachunków bankowych.

Transkrypt

1 Uniwersytet Warszawski Wydziaª Matematyki, Informatyki i Mechaniki Sebastian Tomaszewski Nr albumu: Obsªuga bª dów w procesach automatycznej konsolidacji rachunków bankowych. Praca magisterska na kierunku INFORMATYKA Praca wykonana pod kierunkiem dra Piotra Chrz stowskego-wachtla Instytut Informatyki listopad 2009

2 O±wiadczenie kieruj cego prac Potwierdzam,»e niniejsza praca zostaªa przygotowana pod moim kierunkiem i kwalikuje si do przedstawienia jej w post powaniu o nadanie tytuªu zawodowego. Data Podpis kieruj cego prac O±wiadczenie autora (autorów) pracy wiadom odpowiedzialno±ci prawnej o±wiadczam,»e niniejsza praca dyplomowa zostaªa napisana przeze mnie samodzielnie i nie zawiera tre±ci uzyskanych w sposób niezgodny z obowi zuj cymi przepisami. O±wiadczam równie»,»e przedstawiona praca nie byªa wcze±niej przedmiotem procedur zwi zanych z uzyskaniem tytuªu zawodowego w wy»szej uczelni. O±wiadczam ponadto,»e niniejsza wersja pracy jest identyczna z zaª czon wersj elektroniczn. Data Podpis autora (autorów) pracy

3 Streszczenie TODO:Na razie tylko skopiowanie starego tytuªu Mechanizmy reagowania na wyj tkowe sytuacje w dªugotrwaªych procesach biznesowych. Rozwój, porównanie i zastosowanie w systemie obsªugi cash pooli. Sªowa kluczowe 11.3 Informatyka Dziedzina pracy (kody wg programu Socrates-Erasmus) TODO J. Computer Applications J.1. Administrative Data Processing J.1.3. Financial Klasykacja tematyczna Tytuª pracy w j zyku angielskim

4

5 Spis tre±ci Wprowadzenie Historia transakcji Transakcyjno± ACID Punkt zapisu Transakcje rozproszone Transakcje zagnie»d»one OLTP Dªugotrwaªe zadania L-R Transakcje ªa«cuchowe Saga Inne ACTA Wyj tki Idea J zyki programowania U»yteczno± Sieci przepªywu pracy Modele transakcji dla sieci przepªywów Narz dzia Usªugi sieciowe Business Process Management(BPM) Transakcje Podsumowanie Obecny kierunek rozwoju Pami transakcyjna Siatki transakcji Specykacje formalne J zyki modelowania kompensowalnych przepªywów Rozszerzenia algebr procesów System obªugi cash pooli Cash pool Zarz dzanie pªynno±ci Zasada dziaªania Sytuacja prawna

6 Korzy±ci Platforma Motywacja System dedykowany Procesy w systemie Sposób dziaªania Procesy Proces ko«ca dnia Proces pocz tku dnia Proces dzienny Kroki procesów Obsªuga sytuacji nieprawidªowych Analiza narz dzi Zr by Technologie Propozycja rozwi zania Podsumowanie Bibliograa

7 Wprowadzenie TODO:ok 2 stron 5

8

9 Rozdziaª 1 Historia transakcji Czym jest transakcja? W zasadzie, koncepcja transakcji byªa wynaleziona ju» 6000 lat temu, kiedy Sumerowie zapisywali na glinianych tablicach stan królewskich wªo±ci, w celu badania ich zmian. Ogólnie mówi c, transakcja jest transformacj z jednego stanu w inny. W trakcie tysi cy lat pomysª ten zaadoptowano w wielu innych dziedzinach»ycia, np. w ±wiecie biznesu transakcja jest umow miedzy kupuj cym a sprzedaj cym na wymian towaru i pieni dzy. W okresie rozwoju baz danych na przeªomie lat 60-tych i 70-tych transakcje zawarto w pierwszych urz dzeniach obsªugi transakcji takich jak CICS opracowany przez IBM. W bazach danych rzeczywisty stan ±wiata zewn trznego modeluje si jako relacje i krotki, a transformacje s modykacjami danych. Patrz c z tej perspektywy widzimy transakcje jako grup operacji u»ywanych w celu dost pu albo zmiany bazy danych. Pomimo i» wiedziano,»e atomowo± (TODO:ref) jest bardzo wa»nym problemem, nie powstaª»aden formalny model a implementacje bazowaªy na reguªach empirycznych. Pierwsza próba formalnego przedstawienia kontroli wspóªbie»no±ci miaªa miejsce w pracy [Eswa76]. Wprowadzaªa ona dwufazowe blokowanie, a pó¹niej staªa si podstaw teorii szeregowalno±ci. Teoria ta jest ci gle fundamentem dzisiejszych rozwi za«zarz dzania wspóªbie»no±ci w bazach danych. W tym samym czasie badano równie» problem odporno±ci na bª dy, który tak»e przedostaª si do ±wiata baz danych. W [Gray78] opisane zostaªy protokoªy DO-UNDO-REDO oraz WAL(ang. write-ahead logging) Transakcyjno± ACID Transakcje ACID s bardzo wa»ne w informatyce, dlatego mechanizmy te opisano w wielu publikacjach, m. in. [Bern87], [Gray93], [Weik02]. W tym podrozdziale nie przeprowadz dogª bnej analizy tej tematyki. Ogranicz si do przedstawienia gªównych zaªo»e«zarz dzania transakcjami w celu opisania idei, która posªu»yªa do dalszego rozwoju mechanizmów transakcyjnych. Atomowo± Wyobra¹my sobie sytuacj kiedy wielow tkowy program korzysta ze wspóªdzielonej pami ci w wieloprocesorowej maszynie. Niskopoziomowe operacje sprz towe takie jak atomowa 7

10 wymiana 1 s podstawowymi funkcjami, dzi ki którym mo»na konstruowa bardziej zªo»one mechanizmy synchronizacji. Elementarne operacje maj bardzo proste wªasno±ci, przez co s bardzo wa»ne w programowaniu wspóªbie»nym, gdy» uªatwiaj dowodzenie poprawno±ci i zapewnienie,»e zªo»one operacje z nich konstruowane s zgodne ze specykacj. Zªo»ona operacja jest deniowana jako sekwencja akcji, które mog by zarówno atomowe, jak i zªo»one. Gªówn ide transakcji jest przeniesienie wªasno±ci funkcji skªadowych na ich zªo»enie. Do opisania wyniku akcji, potrzebujemy kilku podstawowych poj. wiat (zwany równie» systemem) skªada si z obiektów, ka»dy z nich ma dobrze zdeniowany stan (zazwyczaj warto±ci zbioru zmiennych). Globalny stan ±wiata jest sum stanów pojedynczych obiektów. Proces jest sekwencj akcji, które s zdeniowane nast puj co: przy danym stanie pocz tkowym systemu oraz podanej ewentualnie warto±ci wej±ciowej, wynikiem wykonywanej samotnie akcji jest sprowadzenie systemu do stanu ko«cowego w sko«czonym czasie oraz ewentualnie dostarczenie wyniku. Dla ka»dej akcji, ko«cowy stan oraz wynik s okre±lone jako funkcja ze stanu pocz tkowego oraz warto±ci wej±ciowej. Caªy model jest w zasadzie maszyn stanow. Wykonania procesów mog ponosi pora»k. Ma to miejsce, gdy zachowanie systemu (albo którego± z jego komponentów) nie speªnia specykacji. Bª dy dzieli si na ró»ne klasy w zale»no±ci od ich wa»no±ci i poziomu zakªócania pracy systemu. Tutaj skupimy si jedynie na bª dach przerywaj cych dziaªanie aplikacji(ang. fail-stop failure): komponent albo dziaªa zgodnie ze specykacj, albo nie dziaªa w ogóle. Teraz dochodzimy do poj cia atomowo±ci, wªasno±ci akcji elementarnych, któr chcemy przenie± równie» na ich zªo»enie. Atomowo± istnieje w dwóch pªaszczyznach: atomowo± wspóªbie»no±ci (ang. concurrency atomicity) We¹my dwie akcje A i B wykonuj ce si niezale»nie we wspóªbie»nych procesach (co oznaczamy jako A B). Je±li»adna nie wykonaªa si bª dnie, to wynik ich dziaªania (przyp. warto±ci wyj±ciowe albo zmiana stanu systemu) jest taki, jak gdyby wykonaªy si po kolei w dowolnej kolejno±ci (A;B albo B;A). Innymi sªowy: zªo»ona operacja przechodzi poprzez stany po±rednie, które s stanami ko«cowymi jej skªadowych. aden z tych stanów nie mo»e by widoczny dla»adnej wspóªbie»nej operacji. Tak przedstawiona atomowo± wspóªbie»na nazywana jest izolacj (ang. isolation). atomowo± awarii (ang. failure atomicity) We¹my akcj A, która wykonana niezale»nie zmienia stan systemu z S1 na S2 (co oznaczamy jako S1 {A} S2). Je±li wyst pi bª d podczas wykonania A stan ko«cowy jest albo S1 albo S2. Oznacza to,»e operacja jest wykonywana w caªo±ci albo wcale. Tak jak poprzednio,»aden stan po±redni nie mo»e by widoczny. Poza bª dami wynikªymi z przyczyn zewn trznych, operacja mo»e zdecydowa o przerwaniu swojego dziaªania i anulowaniu wszystkich wykonanych do tej pory zmian. Tak sytuacj nazwiemy przerwaniem(ang. abort). Je±li S1 {A} S2, to wynikiem przerwania wykonania A jest przywrócenie w systemie stanu S1, co nazywa si odwróceniem(ang. rollback). Dzi ki atomowo±ci bez straty ogólno±ci mo»emy przenie± t sytuacj to wykonania wi kszej liczby wspóªbie»nych operacji. Transakcje w bazach danych Transakcje w przedstawionym znaczeniu zostaªy po raz pierwszy u»yte w systemach zarz dzania bazami danych. Wzbogacono je o dwie dodatkowe cechy: akcji 1 atomowa wymiana wymiana zawarto±ci rejestru procesora i jednostki pami ci w jednej niepodzielnej 8

11 trwaªo± (ang. durability) trwaªo± oznacza,»e je±li transakcja si powiedzie, czyli wykona si bezbª dnie i nie zostanie odwrócona, to zmiany wykonane na bazie s zachowane. Oczywi±cie stan mo»e zosta zmieniony przez kolejne transakcje. Operacja oznaczaj ca pomy±lne zako«czenie transakcji jest nazywana zatwierdzeniem(ang. commit). Trwa- ªo± oznacza,»e kiedy transakcja jest zatwierdzona, zmiany które wykonaªa s odporne na awarie. Wyª czamy jednak katastrofy, czyli rzadkie zdarzenia, które mog skutkowa uszkodzeniem sprz tu i utrat danych. spójno± (ang. consistency) spójno± w bazach danych jest wyra»ana zazwyczaj jako zbiór ogranicze«integralno±ci, np. predykatów okre±lanych na jej stanie. Te ograniczenia odzwierciedlaj wªasno±ci rzeczywistych obiektów reprezentowanych przez baz danych (konta bankowe, zawarto± biblioteki). Poniewa» wymagamy spójno±ci podczas caªego»ycia bazy danych, transakcja przeprowadza system z jednego spójnego stanu w inny spójny stan. Podczas wykonania, niektóre po±rednie stany mog by niespójne, ale, dzi ki izolacji, nigdy nie s widoczne. Spójno± jest okre±lana poprzez wymogi konkretnej aplikacji, dlatego cz sto same mechanizmy bazodanowe s niewystarczaj ce i odpowiedzialno±ci programisty jest pisanie kodu, który zachowa stan danych spójnym w szerszym zakresie. Wªasno±ci ACID(ang. Atomicy, Consistency, Isolation, Durability) zostaªy przedstawione we wczesnych latach 80-tych (patrz poz. [Gray81]). Przegl d wczesnych technik odtwarzania danych znajduje si w [Haer83]. Wszystkie te poj cia znalazªy zastosowane przy projektowaniu wielu systemów zarz dzania bazami danych, w tym przeªomowego System-R, który jako pierwszy wykorzystywaª j zyk zapyta«sql i byª dowodem na to,»e relacyjne bazy danych potra by wydajne (patrz poz. [GMBL81]). Powy»sze wªa±ciwo±ci uj to w matematycznej teorii szeregowalno±ci. Transakcje ACID odniosªy wielki sukces, gdy» dzi ki swoim cechom zapewniaªy,»e stan systemu jest spójny nawet w przypadku bª dów oraz nietypowych zdarze«, pomimo wspóªbie»nego wykonywania zada«. Za swoj prac i wkªad w rozwój informatyki Jim Gray otrzymaª Nagrod Turinga w roku Mechanizm dziaªania Transakcje sprzyjaj rozdzieleniu koncepcji. Pozwalaj programistom skoncentrowa si na logice aplikacji (m. in. dbaniu o spójno± danych biznesowych), podczas kiedy system zarz dzania transakcjami (inaczej zarz dca transakcji) odpowiada za zapewnienie pozostaªych wªasno±ci transakcji (atomowo±, izolacja i trwaªo± ). Sªu» do tego nast puj ce mechanizmy (patrz poz. [Lewi02]): Izolacj zapewnia kontrola wspóªbie»no±ci, podstawowym mechanizmem jest tu blokowanie obiektów. System zarz dzania baz danych zakªada blokady na odpowiednich obiektach, kiedy programy z nich korzystaj. Blokady s utrzymywane dopóki transakcja si nie zako«czy, zapobiegaj c przed odczytem niespójnych danych przez wspóªbie»ne transakcje w czasie trwania niesko«czonej transakcji. Inna technik kontroli wspóªbie»- no±ci jest stemplowanie obiektów datami systemowymi i zarz dzanie dost pem poprzez kontrol stempli. Wi cej informacji w [Rama97]. Atomowo± jest zapewniana przez odzyskiwanie(ang. recovery), które wykorzystuje mechanizmy logowania. Ka»da modykacja bazy danych jest zapisywana w tabeli loguj cej przechowywanej niezale»nie od samych danych. Odwrócenie mo»e si wykonywa przez przywrócenie poprzednich warto±ci ka»dego obiektu znalezionego w logu. 9

12 Trwaªo± zale»y od atomowo±ci awarii i opiera si na wykorzystaniu trwaªego magazynu danych(ang. stable storage). Jest to mechanizm gwarantuj cy,»e zapisane w nim dane s odporne na uszkodzenia (wykluczaj c katastrofy). Techniki implementacji takich mechanizmów zostaªy opisane w [Lamp79]. Podobnie jak w tracie odwracania, po awarii aktualny stan mo»e by odtworzony na podstawie logu. Zauwa»my,»e blokowanie jest niezb dne, aby logowanie dziaªaªo prawidªowo. Je±li kilka czynno±ci zmodykowaªo ten sam obiekt w tym samym czasie, to nie byªoby wiadome który stan powinien zosta odtworzony, gdyby jedna z operacji wymagaªa cofni cia. Programowanie System zarz dzania transakcjami udost pnia swoim u»ytkownikom prosty interfejs. Skªadnia operacji mo»e si ró»ni w zale»no±ci od systemu, ale podstawowy interfejs zazwyczaj skªada si z nast puj cych funkcji: begin transaction rozpocz cie nowej transakcji. commit transaction poprawne zako«czenie transakcji (zmiany zostaj trwale zapisane). abort/rollback transaction przerwanie wykonania transakcji i anulowanie zmian wykonanych od jej rozpocz cia do tego momentu. Powy»sze operacje sªu» do rozgraniczania zasi gu transakcji, czyli rozdzielenia operacji b d cych cz ±ci transakcji. Granice mog by dokªadnie okre±lone przez programist, b d¹ automatycznie wygenerowane na podstawie deklaracji w ±rodowisku programowania. Kluczowe znaczenie ma fakt,»e mechanizmy ACID powalaj caªkowicie ukry przed programist zarówno bª dy jak i przeploty 2. Mo»e on po prostu pisa kod wykonuj cy wa»ne operacje biznesowe oraz opakowywa kod w konstrukcj transakcyjn. System zapewni to,»e program zawsze wykona si jakby byª jedyn i niepodzieln jednostk pracy(ang. unit of work) caªkowicie niezale»nie od innych akcji, które mog dziaªa wspóªbie»nie z jego wykonaniem. Je±li operacja zako«czy si z powodzeniem, to zarz dca transakcji zapewni zapisanie zmian w bazie danych pomimo mo»liwych bª dów kolejnych transakcji. Gdy jednak wykonaªa si cz ± pracy, ale bª d powstrzymaª program przed zako«czeniem, wówczas system wykona odwrócenie niesko«czonej akcji, czyli przywróci dane do stanu sprzed rozpocz cia operacji. Ograniczenia W rzeczywisto±ci istniej bardziej ogólne wªa±ciwo±ci ni» ACID: VCRP(ang. Visibility, Consistency, Recovery, Permanence), które mog sªu»y jako warunki oceny modelu transakcji (patrz poz. [Warn93]): Widoczno± (ang. visibility) okre±la mo»liwo± dost pu do wyników wykonywanej transakcji przez inne transakcje. Spójno± (ang. consistency) odnosi si do poprawno±ci stanu bazy danych po zatwierdzeniu transakcji. Odzyskiwalno± (ang. recovery) oznacza zdolno± do przywrócenia bazy danych do poprzedniego poprawnego stanu w przypadku napotkania bª du. 2 przeplot wspóªbie»ne wykonanie dwóch lub wi cej sekwencji transakcji, w których poszczególne transakcje jednej sekwencji mog wykonywa si naprzemiennie z transakcjami z innych sekwencji 10

13 Trwaªo± (ang. permanence) to mo»liwo± zmiany stanu bazy danych przez zatwierdzon transakcj bez straty wyniku pomimo awarii. Je±li u»yjemy miary VCRP do oceny standardowego modelu transakcji (zwanego równie» pªaskim), to otrzymujemy wªasno±ci ACID, które s podstaw tych stosunkowo prostych transakcji. Okazaªy si one bardzo u»yteczne w tradycyjnych aplikacjach bazodanowych, gdzie czas wykonania jest krótki, ilo± wspóªbie»nych transakcji jest maªa a system baz danych znajduje si na jednym serwerze. To co kiedy± byªo du» zalet, okazaªo si sporym ograniczeniem dla aplikacji, które wymagaj wspóªpracuj cych wspóªbie»nych aktywno±ci, operuj na kilku bazach danych lub mog po prostu trwa dªugo. Aby temu zaradzi, zacz to tworzy rozszerzone modele transakcji, które miaªy by bardziej elastyczne i przezwyci»a te ograniczenia Punkt zapisu Punkt zapisu lub inaczej punkt po±redni(ang. save point) przedstawiono po raz pierwszy w [Astr76] jako mechanizm umo»liwiaj cy wykonywanie cz ±ciowego odwracania. Pozwala on na oznaczenie pewnego miejsca w transakcji jako specjalnego momentu jej wykonania i nazwanie go. W jednej transakcji mo»e istnie wiele punktów zapisu. W ka»dym punkcie po±rednim, zapami tywane s dane przechowuj ce stan kontekstu bazy danych u»ywanego przez transakcje. Kiedy transakcja si nie powiedzie, mo»e odtworzy stan do okre±lonego punktu zapisu przywracaj c kontekst i zwalniaj c blokady obiektów zaªo»one podczas wykonania od tego punktu. Mechanizm ten jest bardzo u»yteczny przy implementacji zªo»onej obsªugi bª dów w aplikacjach bazodanowych - je±li bª d wyst pi w ±rodku transakcji wykonuj cej wiele operacji, to mo»e si ona cofn do podanego punktu zapisu bez konieczno±ci anulowania caªej transakcji. Wykorzystanie punktów zapisu przy odwracaniu nie jest jednak proste i wymaga dobrego przemy±lenia, poniewa»: po cofni ciu si do punktu zapisu i odtworzeniu transakcja kontynuuje przetwarzanie a» si zako«czy, w przeciwie«stwie do anulowania, gdzie po przywróceniu stanu wykonanie zostaje przerwane, pomimo odtworzenia stanu bazy danych do podanego puntu zapisu, warto±ci lokalnych zmiennych transakcji nie s cofane, co oznacza,»e transakcja musi kontynuowa prac w inny sposób ni» planowano pierwotnie, po odtworzeniu punktu zapisu, usuni te zostaj punkty zapisu utworzone od punktu do którego przywracamy do miejsca wywoªania przywrócenia. Mechanizm punktów zapisu mo»na u»y z prostymi pªaskimi transakcjami ACID. Jednak wi ksz rol odegraª on w rozwoju zaawansowanych modeli transakcji: rozproszonych, zagnie»d»onych, ªa«cuchowych, itd. Modele te byªy dedykowane do okre±lonego typu aplikacji biznesowych i s przykªadem zastosowania mechanizmu punktu zapisu do rozwi zania ró»nych problemów. Punkty bezpiecze«stwa s opisane w standardzie SQL oraz s wspierane w pewnej formie w niektórych bazach danych: PostgreSQL, Oracle, Microsoft SQL Server, MySQL, DB2, SQLite (od 3.6.8), Firebird and Informix (od 11.50xC3). 11

14 Transakcje rozproszone Do tej pory zakªadali±my,»e transakcja wykonuje si na jednej bazie danych. Wraz z rozwojem potrzeb i technologii powstaªo wymaganie, aby wykonywa transakcje na obiektach, które mog znajdowa si w ró»nych systemach baz danych dost pnych przez sie. Zarz dzanie transakcjami w rozproszonym systemie opiera si na wspóªpracy lokalnych systemów zarz dzania transakcjami. Aby zachowa globaln spójno±, zarz dcy musz u»ywa wspólnego protokoªu uzgadniania. Gªównym przedmiotem uzgodnienia jest wspólna decyzja, kiedy wykona zapisanie a kiedy anulowanie transakcji. Decyzja musi by spójna pomi dzy wszystkimi uczestnikami transakcji. Oznacza to,»e rozproszony zapis powinien by atomowy (wszyscy albo nikt). Jest to gªówny problem przy transakcjach rozproszonych i w tej sekcji przedstawi najwa»niejsze pomysªy na jego rozwi zanie. Warto doda,»e protokóª, który mo»e by u»yty do uzgadniania zapisu transakcji, mo»e by równie» u»yty do zarz dzania wspóªbie»no±ci transakcji poprzez tzn. porz dkowanie zapisu (patrz poz. [Raz92]). Atomowe zapisywanie Przyjrzymy si na pocz tku wªasno±ciom, które powinien speªnia poprawny protokóª zatwierdzania rozproszonych transakcji. W rozproszonym systemie zarz dzania transakcjami lokalny proces kontroluje prace lokalnego zarz dcy i obsªuguje komunikacj z podobnymi procesami w innych w zªach sieci. Zakªadamy,»e: ª czno± jest rzetelna, czyli wiadomo±ci nie s zmieniane w trakcie dostarczania, oraz równoczesna, czyli»aden w zeª nie b dzie znacz co spó»niony i mo»na przyj górne ograniczenie na czas odpowiedzi. Dodatkowo zakªadamy,»e bª dy poª czenia lub samych procesów nie rozdziel sieci. procesy mog napotyka bª dy. W takiej sytuacji procesy przestaj wykonywa operacje, nie wykonuj nieprawidªowych operacji oraz nie zapominj swojego stanu. Poprawny proces to taki, który zawsze si powodzi. ka»dy w zeª posiada trwaªy magazyn danych (TODO:odnosnik do ACID??). Zaªo»enie o rzetelno±ci i równoczesno±ci ª czno±ci jest potrzebne, aby zapewni,»e uzgodnienie przy u»yciu protokoªu wykona si w sko«czonym czasie. Transakcja ko«czy si, kiedy którykolwiek proces uczestnicz cy w transakcji wy±le» danie zatwierdzenia b d¹ anulowania transakcji. W tym momencie rozpoczyna si uzgadnianie, w którym ka»dy uczestnik mo»e odda gªos czy jest gotowy do wykonania lokalnego zapisu czy nie. Aby transakcja zostaªa zatwierdzona, ka»dy proces musi chcie zatwierdzenia, w przeciwnym przypadku transakcja musi by przerwana. Przed» daniem zatwierdzenia, którykolwiek z uczestników mo»e spontanicznie (nie sugeruj c si wspóln decyzj ) zdecydowa,»e anuluje swoj cz ± transakcji. Podstawowym wymaganiem dla ka»dego protokoªu jest to, aby wszystkie procesy byª zgodne czy transakcja jest zatwierdzona, czy anulowana. Ka»dy proces zaczyna w stanie pracuj cy (patrz rys. 1.1), w którym mo»e zdecydowa, czy chce zatwierdzi, czy anulowa transakcj. Anulowanie skutkuje prostym przej±ciem do stanu anulowany. Je±li za± zdecyduje,»e chce zapisa, to przechodzi do stanu gotowy, a nast pnie do stanu zatwierdzony. Celem protokoªu jest to, aby wszystkie procesy osi gn ªy stan zatwierdzony b d¹ wszystkie osi gn ªy stan anulowany. Transakcja mo»e zosta zatwierdzona, wtedy i tylko wtedy gdy wszystkie procesy s w stanie zatwierdzony. Poprawny protokóª powinien dopuszcza jedynie nast puj ce zmiany stanów: 12

15 Rysunek 1.1: Stany procesów w rozproszonej transakcji proces mo»e zmieni stan z pracuj cy na gotowy. je±li proces jest w stanie gotowy oraz wszystkie procesy s w stanie gotowy albo zatwierdzony, to proces mo»e zmieni stan na zatwierdzony. je±li proces jest w stanie pracuj cy albo gotowy oraz»aden proces nie jest w stanie zatwierdzony, to proces mo»e zmieni stan na anulowany. gdy jeden proces wejdzie do stanu zatwierdzony b d¹ anulowany, wówczas zostaje tam na zawsze. Te wªasno±ci skutkuj tym,»e kiedy jaki± proces wejdzie do stanu zatwierdzony,»aden inny proces nie mo»e wej± do stanu anulowany, i odwrotnie. Implikuj one równie»,»e transakcja mo»e zosta zatwierdzona jedynie w nast puj cym scenariuszu: 1. wszystkie procesy weszªy do stanu gotowy, w dowolnej kolejno±ci 2. wszystkie procesy weszªy do stanu zatwierdzony, w dowolnej kolejno±ci Osi gni cie celu algorytmu nie jest proste w modelu, w którym procesy mog napotyka bª dy b d¹ zosta odizolowane przez bª d komunikacji. Trywialnym rozwi zaniem jest to, aby ka»dy proces zawsze przechodziª do stanu anulowany, ale taki protokóª nigdy nie doprowadzi do zatwierdzenia transakcji, wi c jest bezu»yteczny. Dodatkowo z twierdzenia [Fisc85] wynika,»e deterministyczny, czysto asynchroniczny algorytm nie mo»e jednocze±nie speªnia postawionych wymaga«oraz gwarantowa uzgodnienia zatwierdzenia transakcji w sytuacji napotkania bª dów. Dlatego wymagania»ywotno±ci dla protokoªu s okre±lone nast puj co: nietrywialno± je±li caªa sie jest bezbª dna podczas wykonania algorytmu, wtedy: a) je±li wszystkie procesy osi gn stan gotowy, to wszystkie osi gn stan zatwierdzony; b) je±li który± proces osi gnie stan anulowany, to wszystkie procesy osi gn stan anulowany nieblokowalno± je±li przez caªy czas wystarczaj co du»y fragment sieci w zªów jest bezbª dny wystarczaj co dªugo 3, to wszystkie procesy wykonywane w tych w zªach osi gn zgodnie stan zatwierdzony, b d¹ anulowany. Dwufazowe zatwierdzanie Dwufazowy protokóª zatwierdzania, w skrócie 2PC(ang. two-phase commit), zostaª zaproponowany w pracy [Gray78]. Wspóln decyzj podejmuje koordynator, który jest jednym z uczestników transakcji. 3 zale»y od czasu odpowiedzi poprawnych procesów oraz pr dko±ci sieci 13

16 Rysunek 1.2: Uzgadnianie w 2PC Protokóª zaczyna si, kiedy jaki± proces wejdzie do stanu gotowy i prze±le komunikat do koordynatora. Po otrzymaniu wiadomo±ci koordynator sam przechodzi do stanu gotowy i wysyªa komunikat przygotuj si do wszystkich innych procesów. Po otrzymaniu wiadomo±ci, ka»dy uczestnik, który ci gle przebywa w stanie pracuj cy, mo»e zmieni stan na gotowy i wysªa komunikat. Kiedy koordynator otrzyma wiadomo± gotowy od wszystkich procesów, mo»e wej± do stanu zatwierdzony i poinformowa uczestników, którzy po otrzymaniu wiadomo±ci zatwierd¹ mog równie» wej± do stanu zatwierdzony. Rysunek 1.2 jest uproszczony. Wiadomo± od koordynatora o konieczno±ci przygotowania jest sugesti,»e je±li który± proces jeszcze tego nie zrobiª, to wªa±nie nastaª odpowiedni moment. W rzeczywisto±ci ka»dy proces mo»e w dowolnej chwili wej± do stanu gotowy i wysªa komunikat. Jest to równoznaczne z jego odpowiedzi na komunikat koordynatora o przygotowaniu si. Ka»dy proces mo»e spontanicznie wej± do stanu anulowany je±li byª w stanie pracuj cy, a koordynator mo»e wej± do stanu anulowany, je±li nie byª w stanie zatwierdzony. Kiedy koordynator anuluje transakcje, wysyªa informacje do wszystkich procesów, które po otrzymaniu wiadomo±ci zmieniaj stan na anulowany Bª dy W protokole zatwierdzania transakcji, je±li jeden b d¹ wi cej procesów napotka bª d, transakcja zazwyczaj jest przerywana. W 2PC, je±li koordynator nie otrzyma wiadomo±ci o gotowo±ci od którego± uczestnika wystarczaj co szybko, anuluje transakcje i informuje o tym pozostaªe procesy. Zauwa»my,»e bª d koordynatora mo»e spowodowa zablokowanie protokoªu zanim koordynator zostanie naprawiony, b d¹ wybrany nowy. W szczególno±ci, gdy bª d nast pi po tym jak wszyscy uczestnicy potwierdzili przej±cie do stanu gotowy, wówczas»aden z nich nie jest w stanie stwierdzi czy koordynator zatwierdziª czy anulowaª transakcj. Nieblokuj cy protokóª zatwierdzania to taki, w którym bª d jednego procesu nie stoi na przeszkodzie w zdecydowaniu przez pozostaªe czy transakcja jest zapisana czy anulowana. Powstaªo kilka takich protokoªów, a cz ± z nich zostaªa zaimplementowana. Ich autorzy próbuj zazwyczaj naprawi 2PC poprzez wybór innego koordynatora w sytuacji wyst pienia bª du u aktualnego. Jednak»aden z nich nie proponuje kompletnego algorytmu, który za- 14

17 pewni wszystkie wymagania poprawno±ci. Dla przykªadu, w bardzo znanej publikacji na temat nieblokuj cego zatwierdzania [Bern87] brakuje wyja±nienia co proces powinien zrobi, je±li otrzyma wiadomo±ci od dwóch innych procesów, twierdz cych,»e s koordynatorem. Zapewnienie,»e taka sytuacja nie nast pi jest problemem równie trudnym jak implementacja protokoªu zatwierdzania transakcji. Inne podej±cie zostaªo zaprezentowane w pracy [Gray06]. Autorzy prezentuj Paxus Commit - protokóª, który u»ywa wielu koordynatorów i jest nieblokuj cy, je±li wi kszo± z nich pracuje. Idea algorytmu wywodzi si od problemu jednomy±lno±ci w programowaniu rozproszonym, dotyczy on zbioru procesów uzgodniaj cych pewn warto± (patrz poz. [Dwor88]). Rozwi zaniem jest algorytm asynchroniczny Paxos (patrz poz. [DePr97]). Z jego wykorzystaniem autorzy skonstruowali protokóª zatwierdzania transakcji, a 2PC okazuje si jego zdegenerowanym przypadkiem u»ywaj cym jednego koordynatora, nieblokuj cym si je±li ten pracuje. W teorii systemów rozproszonych istniej wyniki wskazuj ce,»e zatwierdzanie transakcji jest trudniejsze ni» problem jednomy±lno±ci (patrz poz. [Guer95]). Bazuj one jednak na silniejszej denicji zatwierdzania transakcji. Mówi ona,»e transakcja powinna by zatwierdzona, je±li wszyscy uczestnicy s bezbª dni i weszli do stanu gotowy, nawet je±li wyst piªy nieprzewidywalne opó¹nienia poª czenia. Jednak zaªo»yli±my na pocz tku,»e wymaganie nietrywialno±ci, musi by speªnione jedynie przy dodatkowym warunku nieblokowalno±ci, czyli, odwrotnie w stosunku do silniejszej denicji, wszystkie wiadomo±ci s dostarczane w jakim± znanym limicie czasu. Silniejsza denicja zatwierdzania transakcji nie jest implementowalna w typowych systemach transakcyjnych, je±li przypadkowe opó¹nienia musz by tolerowane. Narz dzia Pierwsze rozproszone bazy danych powstaªy na pocz tku lat 80-tych. System R* (patrz poz. [Moha86]) byª rozproszonym rozszerzeniem Systemu-R. Inne wpªywowe systemy transakcyjne to: Camelot, pó¹niej znany jako Encina (patrz poz. [Eppi91]) oraz UNITS (Unix Transaction System), pó¹niej znany jako Tuxedo (patrz poz. [Andr96]). Zarówno Encina jak i Tuxedo staªy si produktami, które s u»ywane do dzi±. Najbardziej wpªywowy na rozwój rozproszonych transakcji byª model X/Open Distributed Transaction Processing (X/Open DTP)(patrz poz. [XOpen96]). Jest to architektura programistyczna zapewniaj ca wielu aplikacjom dost p do wspóªdzielonych zasobów udost pnianych przez wielu zarz dców zasobów (np. bazy danych) i pozwalaj ca, aby ich praca byªa koordynowana poprzez globaln transakcj. Model X/Open DTP jest uwa»any jako referencyjna implementacja protokoªu 2PC. 15

18 Transakcje zagnie»d»one Koncepcja transakcji zagnie»d»onych zaprezentowano w [Moss85]. Motywacj do jej powstania byªo umo»liwienie wspóªbie»no±ci w obr bie transakcji oraz potrzeba wi kszej ziarnisto±ci przy deniowaniu atomowo±ci. Pomysª polega na tym, aby transakcja skªadaªa si z podtransakcji w hierarchiczny sposób tworz c drzewo podtransakcji. Podstawowymi poj ciami s : korze«gªówna transakcja li± podtransakcja nie posiadaj ce wªasnych podtransakcji dziecko podtransakcja pewnej transakcji potomek dziecko - rekurencyjnie rodzic nadtransakcja dla pewnej transakcji przodek rodzic - rekurencyjnie Ka»da podtransakcja mo»e skªada si z kolejnych podtransakcji, lecz tylko li±cie wykonuj operacje na bazie danych. Pozostaªe transakcje w strukturze funkcjonuj jako koordynatorzy. Korze«sªu»y jako granica obejmuj ca wszystkie cz stkowe podtransakcje oraz posiada wszystkie wªasno±ci tradycyjnej transakcji ACID. Caªe drzewo transakcji jest atomowe, szeregowalne oraz odizolowane od innych drzew (transakcji zagnie»d»onych). Dziecko mo»e si rozpocz dopiero po rozpocz ciu si rodzica, a rodzic mo»e zosta zatwierdzony dopiero kiedy wszystkie jego dzieci zostan zako«czone. Ka»da podtransakcja jest atomowa, wi c mo»e zosta anulowana niezale»nie od swojego rodzica. W drzewiastej strukturze mo»liwe jest wspóªbie»ne wykonywanie podtransakcji, o ile nie blokuj si one wzajemnie. Je±li transakcja jest przerywana, wszyscy jej potomkowie musz zosta przerwani. W przypadku, gdy niektóre zostaªy ju» zatwierdzone, zmiany musz zosta wycofane tak, jakby podtransakcje nie zostaªy wykonane. Je±li anulowanie nast piªo w podtransakcji (±wiadomie lub przez bª d), rodzic nie musi automatycznie wykonywa anulowania. Mo»e spróbowa wykona akcje ratunkow : 1. powtórzy podtransakcj, je±li jest prawdopodobie«stwo,»e si powiedzie 2. uruchomi awaryjn podtransakcj do wykonania alternatywnych kroków 3. przerwa, je±li»aden z powy»szych nie mo»e zosta wykonany Dokªadniejszy opis mechanizmów odzyskiwania w transakcjach zagnie»d»onych mo»na znale¹ w [WarRee93]. Kiedy jednak podtransakcja si powiedzie i zatwierdzi, wszystkie zasoby do których miaªa dost p s automatycznie dziedziczone przez rodzica, aby ten mógª przekaza je do kolejnych podtransakcji, b d¹ do rodzica kiedy sam zostanie zatwierdzony. Konikty w dost pie do zasobów mog zaistnie jedynie przy podtransakcjach znajduj cych si w innych gaª ziach drzewa. Korzy±ci Transakcje zagnie»d»one posiadaj trzy gªówne zalety: modularyzacja ka»d skomplikowan transakcj mo»na rozªo»y na proste podtransakcje tworz ce hierarchi 16

19 odtwarzalno± mo»liwo± implementowania odtwarzania na bardziej szczegóªowym poziomie (podtransakcje, a nie caª gªówna transakcja) wspóªbie»no± kontrolowane wspóªbie»ne wykonanie bezkoniktowych podtransakcji Ten model zapewnia osªabione wªasno±ci ACID - korze«posiada tradycyjne wªasno±ci, podtransakcje gwarantuj jedynie atomowo± i izolacj. Podsumowuj c wªasno±ci tego modelu: Ka»de dziecko widzi cz ±ciowe wyniki swoich przodków, oraz wyniki wszystkich innych zatwierdzonych transakcji. Przy zatwierdzeniach podtransakcji stan bazy danych ulega zmianie przez co dane mog nie by spójne, mimo,»e ko«cowy wynik gªównej transakcji mo»e by spójny. Dziecko mo»e utrwali swój wynik w systemie dopiero kiedy rodzic zostanie zatwierdzony. Dopiero zatwierdzenie gªównej transakcji skutkuje zapisaniem danych do systemu. Atomowo± dotyczy ka»dej podtransakcji niezale»nie. Niepowodzenie jednej z nich nie oznacza przerwania rodzica. Dalszy rozwój Idea transakcji zagnie»d»onych przyj ªa si bardzo dobrze, a w pó¹niejszych latach bazowaªy na niej inne modele. W [Weik92] autorzy przedstawili transakcje wielopoziomowe (warstwowe) oraz ich uogólnienie: otwarte transakcje zagnie»d»one. Gªówne zmiany w modelu to (wi cej w poz. [Lewi02]): ka»dej transakcji w drzewie przypisany zostaje poziom w zale»no±ci od architektury systemu. Wszystkie li±cie znajduj si na jednym najni»szym poziomie. podtransakcje wykonuj si sekwencyjnie, a nie wspóªbie»nie. udost pnienie operacji przedzatwierdzenie(ang. pre-commit), która pozwala na zatwierdzenie i utrwalenie podtransakcji przed zatwierdzeniem rodzica. Oznacza to,»e zmiany nie s mo»liwe do odwrócenia w tradycyjny sposób. Kiedy rodzic wykonuje odwrócenie, musi u»y specjalnej transakcji kompensacji, która musi semantycznie odwróci zmiany, a nie po prostu przywróci stan (TODO: ref do SAG). Otwarte transakcje zagnie»d»one ró»ni si od powy»szego modelu tym,»e struktura drzewa nie jest ju» ograniczona do warstw i li±cie mog znajdowa si na ró»nych poziomach. Tradycyjne zagnie»d»one transakcje zapewniaj izolacj na globalnym poziomie, po±rednie wyniki zatwierdzonych podtransakcji nie s widoczne dla wspóªbie»nie wykonywanych podtransakcji. W nowym modelu izolacja zostaje osªabiona, w celu zwi kszenia wspóªbie»no±ci. Transakcje zagnie»d»one s modelem o du»ej sile wyrazu i s powi zane z koncepcj modularyzacji w in»ynierii oprogramowania (patrz poz. [Gray93]). 17

20 OLTP Wi kszo± komercyjnych systemów niededykowanych baz danych u»ywa wy»ej wymienionych mechanizmów, które optymalizowano do wykonywania operacji biznesowych typowych w latach 80-tych i 90-tych. Funkcjonalno± byªa do± prosta, np. zapisanie zamówienia w magazynie, b d¹ wpªaty w banku. Aplikacje tego typu (zwane OLTP) byªy chlebem powszednim w przedsi biorstwach w tamtych czasach. Jednak»e od kilkunastu lat, wraz z rozwojem Internetu, mechanizmy te okazaªy si niewystarczaj ce do nowych wymaga«biznesowych takich jak integracja aplikacji przedsi biorstwa(ang. EAI) oraz integracji przedsi biorstwoprzedsi biorstwo(ang. B2Bi). Nowe aplikacje wyró»nia jedna wa»na cecha: dziaªania(aktywno±ci), które s przez nie automatyzowane trwaj dªugo (od kilku sekund nawet do kilku miesi cy), poniewa» opieraj si na wspóªpracy wielu uczestników oraz cz sto wymagaj interakcji z czªowiekiem. Blokowanie danych na tak dªugi czas jest nieefektywne, gdy» mo»e opó¹ni inne wspóªbie»ne zadania na kilka dni b d¹ dªu»ej. Innym ograniczeniem aplikacji OLTP jest to,»e transakcje oddziaªuj w ramach jednej spójnej jednostki kontroli 4. W przeciwie«stwie do starego modelu, nowoczesne aplikacje dla przedsi biorstw ªami te reguªy, np. jeden proces mo»e anga»owa magazyn, oddziaª logistyczny oraz ksi gowo±. W B2Bi proces cz sto wymaga uczestnictwa ró»nych rm, które mog by wspóªpracownikami jak i konkurencj. Tutaj blokowanie obiektów staje si niedopuszczalne a przewa»nie nieosi galne, gdy»»adne przedsi biorstwo nie pozwoli swojej konkurencji na zablokowanie wªasnych danych. Daje to bardzo ªatw mo»liwo± wykonywania ataków odmowy usªugi(ang. Denial of Service). 4 na pojedynczej bazie danych, pó¹niej rozproszone na kilka instancji, ale zarz dzanych przez jeden system zarz dzania 18

21 1.2. Dªugotrwaªe zadania L-R Dªogotrwaªy Aby zrozumie koncepcj dªugotrwaªych (ang. L-R - long-running) transakcji, zwró my uwag na ich czas»ycia. Dªugo±»ycia transakcji okre±lmy jako minimaln ilo± czasu przez jaki transakcja jest otwarta. Transakcja krótkotrwaªa mo»e zacz si i zako«czy w ci gu kilku sekund. Dªugotrwaªa za± mo»e»y przez minuty, godziny a nawet dni, w zale»no±ci od wymaga«biznesowych i u»ytych technologii. Dodatkowo, ka»da transakcja otwierana na niezdeniowany okres czasu równie» kwalikuje si do miana dªugotrwaªej. Krótkotrwaªe transakcje s ªatwe do obsªu»enia, poniewa», by zachowa wªasno±ci ACID, zasoby przez nie u»ywane mog by po prostu zablokowane na caªy czas trwania. Podobna strategia nie mo»e by zastosowana przy dªugotrwaªych transakcjach. Blokowanie zasobów na dªugi czas mo»e powa»nie zmniejsza wydajno± aplikacji z powodu dªugich czasów oczekiwania oraz zakleszczenia(ang. deadlock). Z dªugotrwaªymi transakcjami mamy doczynienia m.in.: kiedy wykonujemy transakcj z ogromn ilo±ci zapyta«, gdzie bª d jednego z nich mo»e spowodowa bª d caªej transakcji, który b dzie wymagaª odwrócenia do ostatnio zapisanego stanu bazy danych. Taki scenariusz mo»e mie miejsce równie» przy pracy na kilku bazach danych. przy przetwarzaniu wsadowym (ang. batch processing), które zazwyczaj wykonuje si dªugo, zazwyczaj kilka godzin, np. regularna kopia wa»nych danych. W wi kszo±ci przypadków taki proces wykonuje jedynie odczyt danych ¹ródªowych, wi c bªedy nie powinny wyst pi. Lecz w tych rzadkich przypadkach, kiedy dochodzi do modykacji danych, bª d b dzie skutkowaª równie dªugim procesem odwracania. w czasie pseudoasynchronicznych aktywno±ci u»ywaj cych transakcji. S one cz sto wykorzystywane we wspóªbie»nych zadaniach przy komunikacji. Obsªuga odwracania jest bardzo skomplikowana, gdy» mo»e wymaga obsªu»enia niezale»nych, czasami nieznaj cych si procesów. (TODO: wiecej przy usªugach sieciowych) Dlaczego nie transakcje Dªugotrwaªe transakcje s cz sto u»ywane do modelowania rzeczywistych transakcji biznesowych. Samo poj cie transakcji cz sto kojarzy si z transakcjami ACID. Dªugotrwaªe transakcje maj inna semantyk oraz mechanizmy dziaªania, np. rzadziej korzystaj z blokad. W wielu publikacjach jako przykªad prezentuj cy dªugotrwaª transakcj przedstawiane jest organizowanie podró»y. Przyjrzyjmy si takiemu wariantowi: 1. Decyduj si na podró» do Hiszpanii za dwa miesi ce i zamawiam bilet lotniczy i miejsce w hotelu. 2. Hotel, w którym mam rezerwacj, osi ga pewien próg go±ci, powy»ej którego postanawia zwi kszy zatrudnienie na ten okres oraz zamówi wi cej jedzenia. 3. Zamówienie zostaje wysªane do hurtowni. 4. Hurtownia zamawia transport w rmie przewozowej. 19

22 5. Firma przewozowa rezerwuje terminy, a je±li w danym okresie jest du»y popyt to postanawia zainwestowa w nowy samochód dostawczy po tygodniu okazuje si,»e mój wniosek urlopowy zostaª odrzucony z powodu niedotrzymywania terminów w aktualnym projekcie i urlop przesuwa si o 2 tygodnie, wi c staram si przesun wyjazd. Przesuni cie wyjazdu b dzie w najlepszym przypadku wi zaªo si ze strat pewnej kwoty, która zostanie potr cona jako rekompensata. Kupna nowego samochodu nie da si ju» cofn (i by mo»e nie ma potrzeby), a byª to cz ±ciowy efekt naszej decyzji, któr chcemy wycofa. U»ycie transakcji ACID w takiej sytuacji i jej odwrócenie jest niewykonalne. Okre±lenie tego scenariusza jako transakcji mo»e wi c by myl ce, dlatego w dalszej cz ±ci pracy, dla lepszego rozró»nienia, b d u»ywaª okre±le«: zadanie, proces, itp. Problemy dotychczasowych modeli Jedn z najwi kszych przeszkód dla dotychczasowych modeli jest koordynowanie ró»nych technologicznie usªug w jedn dªugotrwaª jednostk pracy, która musi zachowywa si przewidywalnie. Transakcja taka musi zachowywa integralno± biznesow danych w wielu domenach, a wymagania s cz sto okre±lane na poziomie biznesowym a nie bazodanowym. Wªa±ciwe koordynowanie transakcji i spójno±ci swoich danych biznesowych jest podstaw w poprawnym dziaªaniu przedsi biorstwa. Zªo»one aplikacje biznesowe musz wspóªdziaªa z wieloma usªugami w ró»nych moduªach i warstwach, np. autentykacja, wymiana danych, aplikacje wspomagaj ce podejmowanie decyzji (ang. EIS - Executive Information System). Aplikacje mog by powi zane silnie (np. komunikacja synchroniczna) lu¹no (np. komunikacja komunikatami). Czas trwania mo»e by dªugi, wi c prawdopodobie«stwo pora»ki wzrasta. Dodatkowo w caªe zadanie mo»e by wª czony czynnik ludzki, np. przeczytanie maila przez dyrektora i potwierdzenie. Dziaªa«ludzi nie da si przewidzie : przerwy na kaw, wakacje, ±mier, itp. - wszystko mo»e zakªóci oryginalny proces. W tych powodów wymagania odno±nie dªugotrwaªych zada«zostaj zmienione w stosunku do tradycyjnych transakcji, np.: Jedna z aplikacji mo»e napotka bª d, ale caªe zadanie powinno si poprawnie zako«czy. W przypadku bª du caªego procesu, stan mo»e zosta odwrócony do jakiego± miejsca po±redniego, nie za± do samego pocz tku. Identyczno± stanu jest rozumiana w kategoriach biznesowych: po kupieniu biletu i anulowaniu lotu, odwróceniem b dzie zwolnienie miejsca w samolocie, zwrot zapªaty za lot, ale zapewne pomniejszony o kar za wycofanie si. Niektóre wyniki po±rednie musz by widoczne zanim caªe zadanie si zako«czy. Powy»sze wymagania niemal dyskwalikuj wªasno± atomowo±ci wykonywanego zadania. Praca mo»e by zatwierdzana w trakcie wykonywania zadania, a po bª dzie wynik musi zosta odwrócony tak, aby byª zgodny z reguªami biznesowymi. Z tego powodu obsªuga sytuacji bª dnych musi by bardzo dobrze zaprojektowana, gdy» gotowe mechanizmy nie istniej. Przez wiele lat nie powstaªo równie» rozwi zanie problemu izolacji przy dªugich okresach czasu. Algorytmy kontroli wspóªbie»no±ci pracuj ce przez dªugi okres zazwyczaj zaliczaj si do jednej z dwóch grup: pesymistyczne i optymistyczne. Pierwsza grupa zapewnia szeregowalno± transakcji poprzez blokowanie dzielonych zasobów. Blokady s zakªadane na caªy czas trwania transakcji, a inne transakcje oczekuj ce na ten sam zasób s zatrzymane zanim blokada nie zostanie zdj ta. Je±li transakcja trzyma blokad przed dªugi okres, to praca 20

23 wspóªbie»na jest niemo»liwa. Przy drugiej strategii kontroli wspóªbie»no±ci, zakªada si optymistycznie,»e dane u»ywane przez transakcje nie b d zmieniane. Przez zatwierdzeniem nast puje sprawdzenie wyniku i je±li dane okazaªy si niepoprawne (np. zmieniªy si w mi dzyczasie), to nast puje odwrócenie. Przy krótkich transakcjach taki mechanizm, okazuje si bardzo u»yteczny i cz sto pozwala na zwi kszenie wspóªbie»no±ci przy odczytach danych. Niestety prawdopodobie«stwo odwrócenia wzrasta z wydªu»aniem si»ycia transakcji. Z tych powodów wªasno±ci ACID powinny zosta osªabione. Dªugotrwaªe zadania musz zapewnia spójno± danych oraz ich trwaªo±, ale niekoniecznie atomowo± i izolacj w rozumieniu tradycyjnych transakcji Transakcje ªa«cuchowe W tych sytuacjach sprawdza si inne rozbicie transakcji. Transakcje ªa«cuchowe dekomponuj dªug transakcj na mniejsze, wykonywane sekwencyjnie. Zgodnie z [Gray93], pomysª pochodzi z produktów: IBM Information Management System (IMS) oraz bazy danych HP Allbase. Idea jest wariantem mechanizmu punktu zapisu, gdzie podtransakcja b d ca w ªa«cuchu odpowiada przedziaªom pomi dzy dwoma punktami. Istotn ró»nic jest fakt,»e podtransakcja sama w sobie jest atomowa, podczas kiedy przedziaª jest cz ±ci atomowej transakcji. W ªa«cuchu, zatwierdzana podtransakcja wyzwala nast pn, jedna po drugiej, dopóki caªa transakcja ªa«cuchowa nie zostanie zatwierdzona. Atomowo± i izolacja nie s ju» gwarantowane dla caªego ªa«cucha. W przypadku napotkania bª du, wyniki wszystkich poprzednio zatwierdzonych transakcji zostaªy ju» utrwalone, wi c jedynie wyniki aktualnie wykonywanej transakcji s anulowane. W ten sposób odwracanie transakcji mo»e jedynie przywróci system do stanu z pocz tku ostatnio wykonywanej podtransakcji, z pozostaªymi nale»y sobie radzi samemu. Dodatkowym problemem jest fakt,»e cz ±ciowe wyniki po utrwaleniu mógªy zosta wykorzystane przy wykonywaniu innych wspóªbie»nych transakcji Saga Bazuj c na idei transakcji ªa«cuchowych w pracy [Garc87] autorzy przedstawiaj Sag - kombinacj mechanizmu kompensacji i odwracania. Model ten staª si podstaw wielu pó¹niejszych narz dzi obsªugi zaawansowanych transakcji. Podtransakcje Tak jak w transakcjach ªa«cuchowych, pomysª polega na rozbiciu dªugotrwaªej transakcji na sekwencje mniejszych, grupuj cych powi zane operacje. Ka»da z nich zachowuje wªasno±ci ACID, natomiast sama saga nie. Podtransakcje mog by wykonywane w przeplocie podtransakcjami z innych sag (patrz rys. 1.3). Kompensacje Na poziomie ka»dej podtransakcji, po bª dzie mo»e ona zosta odwrócona w tradycyjny sposób. Jednak poprzednie transakcje w sekwencji sagi, zostaªy ju» zatwierdzone i jest za pó¹no na ich odwrócenie. W momencie kiedy drug, b d¹ kolejn podtransakcj sagi napotka bª d, saga zostanie w po±rednim stanie, w którym cz ± pracy zostaªa ju» wykonana. W tych sytuacjach u»yteczny staje si nowy mechanizm - kompensacje. Programista powinien dla ka»dej operacji zaprojektowa odpowiedni kompensator, który musi wykona operacje odwracaj ce konkretn podtransakcj. Przy dodawaniu krotki do bazy danych, kompensator 21

24 Rysunek 1.3: Wspóªbie»ne Sagi mo»e j usuwa ; dla operacji wpªaty na konto, kompensator mógªby pobra z konta t sam kwot ; a dla operacji wykonuj cej tylko odczyty danych, wykona si mo»e pusty kompensator. Mechanizm ten powinien naprawi równie» efekty uboczne dziaªania oryginalnego zadania, np. je±li po sprzeda»y dla klienta zostaªa naliczona premia, to kompensacja anulowanie sprzeda»y powinna równie» przeliczy premi. Odzyskiwanie wstecz Sag S podzielon na podtransakcj mo»emy zapisa jako S = (T 1 ; T 2 ;...T n ), gdzie ka»de T i oznacza podtransakcj. Dla ka»dej podtransakcji T i, poza ostatni (0<i<n), powinien by zdeniowany kompensator C i, który anuluje efekty jej dziaªania. Kiedy podtransakcja napotka bª d i nie mo»e by naprawiona (np. powtórzona), jest przerwana i odwracana. Nast pnie dla ju» wykonanych podtransakcji w sadze, wykonywane s kompensacje w kolejno±ci odwrotnej do kolejno±ci odpowiadaj cych transakcji (patrz rys. 1.4). Wynikiem wykonania sagi S mo»e by : T 1 ; T 2 ;...T n kiedy saga wykonaªa zamierzone zadanie oraz zostaje zatwierdzona T 1 ; T 2 ;...T k ; C k 1 ; C k 1...C 1 (k < n) w sytuacji, gdy podtransakcja T k jest bª dna i zostaje przerwana, oraz wyniki dziaªania jej oraz poprzednich transakcji zostaj odwrócone. Stan po odwróceniu nie musi by jednak identyczny do stanu przed rozpocz ciem sagi, jest jednak równowa»ny biznesowo, poprzez co saga zachowuje biznesowo rozumian atomowo±. Podobnie jak transakcje ªa«cuchowe, sagi mog by przeplatane z innymi wspóªbie»nymi transakcjami, wi c izolacja nie jest zapewniana. Oznacza to,»e spójno± danych nie jest realizowana poprzez szeregowalno±, a w najwi kszym stopniu zale»y od poprawnych kompensacji. Odzyskiwanie w przód Przedstawiony wy»ej mechanizm nie jest jedynym uªatwieniem obsªugi bª dów. Model ten wprowadza równie» odzyskiwanie w przód, które jest realizowane poprzez punkty bezpiecze«- 22

25 Rysunek 1.4: Kompensacja stwa. Jest to rozwi zanie analogiczne to tego z transakcji ACID, z t ró»nic,»e tutaj mo»na ich u»ywa do rozdzielenia kolejnych podtransakcji i utrwalenia stanu sagi. Kiedy podtransakcja napotka bª d, saga mo»e zosta odtworzona do okre±lonego punktu i wykona si ponownie. Je±li mi dzy tym miejscem, a odwracan podtransakcj, wykonaªy si podtransakcje, s one ju» zatwierdzone, wi c wykonywana jest na nich kompensacja (patrz rys. 1.5). Rysunek 1.5: Odzyskiwanie w przód Oczywistym problemem tego podej±cia jest to,»e saga mo»e si nie zako«czy, wchodz c w niesko«czon p tl. Wyj±ciem mo»e by aplikacyjne zliczanie wykonanych powtórze«, a nast pnie przerwanie cyklu poprzez wykonanie alternatywnych operacji. Wprowadza to jednak kolejny poziom zªo»ono±ci obsªugi sytuacji niepoprawnych, tak wi c odzyskiwanie wstecz ª cznie z odzyskiwaniem w przód, powinny by u»ywane bardzo przemy±lanie. 23

26 Warianty Model sag doczekaª si kilku rozszerze«(patrz poz. [Chry92]), które wprowadzaªy wi cej mo»liwo±ci odzyskiwania, przy zachowaniu podstawowych zaªo»e«o strukturze: sagi zatwierdzane nawet, je±li niektóre maªo znacz ce podtransakcje(np. zapisanie logu operacji) zostaªy przerwane. sagi zawieraj ce podtransakcje, których nie trzeba kompensowa. sagi skªadaj ce si z zagnie»d»onych Sag. sagi zawieraj ce awaryjne podtransakcje, które wykonuj alternatywne operacje (zaczynaj wtedy przypomina sieci przepªywu pracy). Podsumowanie Saga stopniowo ukazuje swoje cz ±ciowe wyniki dla innych transakcji, czyli nie posiada wªasno±ci izolacji. Oznacza to,»e ich zastosowanie jest ograniczone. Sagi mog by bez problemów stosowane w sytuacjach, gdzie nie ma du»ej potrzeby izolacji. Ma to miejsce, kiedy podtransakcje ró»nych sag operuj na ograniczonym (rozª cznym) zbiorze danych, b d¹ wykonuj ograniczony zakres operacji(np. same odczyty), przez co automatycznie uzyskiwana jest izolacja ich pracy. W innych przypadkach pomocny b dzie mechanizm kompensacji, którego saga u»ywa, aby zapewnia biznesow atomowo± przez dªugi czas. Po bª dzie transakcji T k, poprawna kompensacja C k powinna sprowadzi baz danych do takiego stanu, na którym mo»na ponownie wykona T k. Je±li si to powiedzie, to wynik tego wykonania b dzie biznesowo identyczny do sytuacji, gdyby pierwsza transakcja T k wykonaªa si bezbª dnie (T k ; C k ; T k == T k ). Niestety nie wszystkie podtransakcje s kompensowalne bez potencjalnej straty spójno±ci. Je±li nie jest mo»liwe zdeniowanie poprawnego kompensatora dla jakiej± operacji, to saga nie jest odpowiednim modelem dla danego dªugotrwaªego zadania. Kolejnym problemem jest konieczno± kaskadowania kompensacji. Mo»e to mie miejsce w momencie, kiedy wyniki ko«cowe kompensowanej podtransakcji, byªy wcze±niej widziane przez inn wspóªbie»n transakcj. Je±li opieraªa si ona na tych wynikach przy wykonywaniu swoich operacji, to mo»e by konieczne kompensowanie równie» niej. Niestety wykrycie takich transakcji mo»e by trudne, poniewa» nie istnieje prosty mechanizm na ich odnalezienie. 24

27 Inne Najwi kszy wpªyw na rozwój mechanizmów transakcyjno±ci miaªo wprowadzenie modeli transakcji zagnie»d»onych oraz Sag. Jednak rozszerzenie pªaskiego modelu transakcji byªo bardzo popularnym tematem bada«na przeªomie lat 80-tych i 90-tych. Powstaªo wiele modeli, które miaªy za zadanie wzbogacenie prostego modelu ACID o konstrukcje zwi kszaj ce jego moc oraz elastyczno± (zestawienia mo»na znale¹ m.in w [Elma92], [Jajo97], [Moha94]). Poni»ej przedstawi kilka ciekawych pomysªów. Transakcje rozdzielane i ª czone Jak wskazuje nazwa, model przedstawiony w pracy [Pu88] pozwala: transakcji rozdzieli si na dwie niezale»ne b d¹ zale»ne transakcje (podziaª zasobów) (patrz rys. 1.6) dwóm zale»nym b d¹ niezale»nym transakcjom poª czy si aby utworzy jedn transakcj (patrz rys. 1.7) na poª czenie powy»szych (patrz rys. 1.8) Rysunek 1.6: Rozdzielenie transakcji T1 na transakcj T1a i T1b. Ka»da jest niezale»na, a zasoby transakcji T1 s rozdzielone miedzy nimi. Rysunek 1.7: Wª czenie transakcji T2 do transakcji T1. Rysunek 1.8: Wydzielenie z transakcji T1, transakcji T3 i wª czenie jej do transakcji T2. Model ten pozwala na wspóªdzielenie zasobów pomi dzy transakcjami, a nawet przekazywanie zasobów z jednej do drugiej. Nie staª si on jednak bardzo popularny, gdy» pomimo zwi kszenia elastyczno±ci, wprowadzaª wiele problemów m.in. skomplikowane ª czenie transakcji, lub nieintuicyjne odwracanie. 25

28 Elastyczne transakcje wielobazodanowe W [Elma90] autorzy przedstawiaj model, który zostaª zaimplementowany w ich j zyku programowania. Model powstaª jako rozszerzenie transakcji zagnie»d»onych w ±rodowisku wielu baz danych. Globalna transakcja skªada si z jednego lub wi cej kroków, a ka»dy z nich wykonuje si na jednym serwerze bazy danych. Dzielimy je na: kroki alternatywne - kroki które mo»na ª czy w zbiory, w ramach których wystarczy poprawne wykonanie jednego z kroków kroki kompensowalne - w przypadku niepowodzenia wykonywana jest zdeniowana podtransakcja kompensacji kroki niekompensowalne (inaczej zwane krytycznymi) - niezb dne do wykonania globalnej transakcji Dodatkowo dla ka»dego z kroków deniuje si ograniczenia okre±laj ce, w jakich warunkach mo»na go wykona. Model aktywno±ci transakcyjnych (ATM) Wszystkie dotychczas przedstawione modele bazowaªy na transakcjach. Praca [Daya91] przedstawia aktywno±ci (transakcje wzbogacone o dodatkowe mechanizmy), które mog si skªada rekurencyjnie z aktywno±ci b d¹ transakcji. Autorzy wykorzystuj rozszerzony model transakcji zagnie»d»onych (patrz poz. [Hsu88]), wi c ich propozycja nadaje si doskonale do wykonywania w rozproszonym systemie, gdy» wspiera wspóªbie»no± podtransakcji. W oryginalnym modelu transakcji zagnie»d»onych transakcje mogªy rozpoczyna podtransakcje, które byªy wykonywane natychmiast. Model rozszerzony jest bardziej elastyczny i rozró»nia dwa rodzaje podtransakcji: odªo»one - wykonanie rozpoczyna si po zako«czeniu rodzica, oddzielone - wykonywane wspóªbie»nie z transakcj wywoªuj c. Aktywno± jest traktowana jako niezale»na jednostka wykonania. Przepªyw sterowania oraz danych z aktywno±ci jest kontrolowany statycznie poprzez skrypty do niej doª czane. Dodatkowo mo»e by on dynamicznie modykowany przez reguªy uruchamiane przez zdarzenia wyst puj ce w trakcie wykonania aktywno±ci. Reguªy s przydatne przy sprawdzaniu ogranicze«, uruchamianiu dodatkowych zada«, b d¹ zmianie wykonania w odpowiedzi na nieprzewidziane warunki. W sytuacjach bª dnych aktywno± mo»na anulowa (zatwierdzone aktywno±ci zostaj kompensowane) b d¹ zast pi alternatywnym krokiem. Niektóre z kroków mo»na oznaczy jako krytyczne, co oznacza,»e ich wynik nie mo»e by widoczny zanim caªa aktywno± nie zostanie zatwierdzona. Dodatkowymi mechanizmami modelu ATM jest komunikacja pomi dzy krokami aktywno±ci poprzez przekazywanie parametrów oraz sprawdzanie statusu aktywno±ci, np. czy jej podtransakcje s aktywne, zatwierdzone, przerwane lub skompensowane. 26

29 ACTA Na pocz tku lat 90-tych przedstawiono nowatorskie podej±cie do tematu. W pracy [Chry90] autorzy prezentuj ACTA - narz dzie grupuj ce cechy dotychczasowych modeli. Jest to formalizm pozwalaj cy na dokªadne wyspecykowanie ró»nych zªo»onych modeli transakcji, przez podanie semantyki wzajemnego oddziaªywania transakcji. Sªu» do tego konstrukcje opisuj ce skutki dziaªania transakcji na inne transakcje oraz skutki dziaªania transakcji na dane. Wyró»nione zostaªy dwa rodzaje skutków dziaªania transakcji na inne transakcje: zale»no± -zatwierdzenia (ang. commit-dependency) - je±li T1 jest zale»na od T2, to T1 nie mo»e zosta zatwierdzona, dopóki T2 nie zostanie zatwierdzona, b d¹ anulowana. zale»no± -przerwania (ang. abort-dependency) - je±li T1 jest zale»na od T2, to je±li T2 zostanie przerwana, to przerwana musi zosta równie» T1. ACTA deniuje oddziaªywania transakcji na obiekty poprzez: zbiory obiektów - ka»dy obiekt u»ywany przez transakcj znajduje si w zbiorze pola widzenia(ang. view set) lub zborze dost pu(ang. access set). Pierwszy zbiór zawiera wszystkie obiekty potencjalnie dost pne dla transakcji, drugi zawiera obiekty, które zostaªy u»yte. Zbiór dost pu bywa te» nazywany zbiorem koniktów. delegowanie - transakcje mog wykonywa zmiany na obiektach poprzez trzy rodzaje delegowania: delegowanie stanu(ang.delegation of state), delegowanie statusu(ang.delegation of status), ograniczone delegowanie(ang.limited delegation). Pierwszy typ opisuje zdolno± delegatora (transakcji deleguj cej) to przenoszenia obiektów ze swojego zbioru dost pu do zbioru dost pu delegowanego (transakcji delegowanej). Delegowanie statusu oznacza zdolno± delegatora do wycofania zmian na obiektach zanim zostan one przeniesione do zbioru dost pu delegowanego. Ostatni rodzaj opisuje zdolno± delegatora do utrwalenia zmian na obiektach w zbiorze pola widzenia delegata, przed dodaniem ich do zbioru dost pu delegata. Mechanizm delegowania pozwala kontrolowa widoczno± obiektów, czyli izolacj transakcji. W poª czeniu z zale»no±ciami zatwierdzenia b d¹ przerwania, delegowanie mo»e równie» okre±la wªasno±ci odtwarzania modelu. ACTA jest meta-modelem, który mo»e zosta z ªatwo±ci u»yty do tworzenia nowych modeli transakcji, poprzez modykacj lub ª czenie istniej cych modeli. Opisuj c model poprzez zale»no±ci, zbiory obiektów oraz delegowanie, otrzymujemy specykacj, która nadaje si do wnioskowania o jego wªasno±ciach, poniewa» ACTA to formalizm oparty o logik pierwszego rz du. Niestety ACTA nie uªatwia w»aden sposób programowania obsªugi transakcji, gdy» skupia si jedynie na formalnej specykacji. ACTA nie jest prosta do zaimplementowania, jako narz dzie deklaratywnego opisu transakcji w aplikacji. W oparciu o ACTA powstaª ASSET (patrz poz. [Bili94]), byªa to próba udost pnienia konstrukcji opisu transakcji na poziomie j zyka programowania. Wprowadzaª on dodatkowe funkcje sªu» ce do tworzenia zale»no±ci, delegowania zasobów oraz nadawania uprawnie«dost pu. ASSET nie opera si na paradygmacie programowania obiektowego, lecz na programowaniu strukturalnym. Niestety dodatkowe operacje nie s dokªadnie opisane i nie ma ±ladów u»ycia go w architekturze rzeczywistego systemu. 27

30 1.3. Wyj tki Podczas, gdy spoªeczno± bazodanowa u»ywaªa transakcji ACID oraz ich rozszerze«jako podstaw w radzeniu sobie z bª dami, zupeªnie inne mechanizmy powstawaªy w j zykach programowania. Nie byªo mowy o wyr czeniu programisty przy reagowaniu na bª d, gdy kod dziaªa niepoprawnie, dane nie speªniaj oczekiwa«, b d¹ system zgªasza informacj o próbie otwarcia nieistniej cego pliku. Zamiast tego skupiono si na wsparciu programisty w oddzieleniu kodu obsªugi sytuacji nienormalnych od cz sto prostszego prawidªowego wykonania Idea Obsªuga wyj tków(ang.exception handling) jest programistyczn konstrukcj oraz mechanizmem sprz towym zaprojektowanym do wyªapywania wyj tków - specjalnych warunków zmieniaj cych przepªyw w wykonaniu programu. Powstaªa w latach 70-tych w j zykach PL/I oraz CLU. Wyj tki s podnoszone(ang. raised) albo rzucane(ang. thrown) przez sprz t lub sam program, aby zasygnalizowa,»e co± poszªo nie tak jak powinno, np. wyst piª bª d dzielenia przez zero. W systemach bez obsªugi wyj tków procedury musiaªby by zwraca specjalny kod bª du. Jednak»e mo»e by to skomplikowane, gdy w procedurze wywoªuj cej musimy za ka»dym razem sprawdza czy warto± zwrócona nie oznacza bª du. Ogólna zasada dziaªania wygl da nast puj co: 1. w momencie pojawienia si wyj tku aktualny stan wykonania jest zapisywany, 2. stos wywoªa«funkcji jest analizowany wstecz w celu odnalezienia funkcji obsªugi, 3. dalsz prac kontynuuje procedura obsªugi wyj tku(ang. exception handler). W zale»no±ci od sytuacji i decyzji programisty procedura ta mo»e pó¹niej kontynuowa zawieszon prac. Oznacz to,»e je±li funkcja f zawieraªa obsªug H bª du E i wywoªaªa funkcj g, która nast pnie wywoªaªa funkcj h, w której wyst piª wyj tek E, to funkcje h i g zostaj przerwane, a wykonanie przejmuje procedura obsªugi H w funkcji f J zyki programowania J zyki programowania ró»ni si znacz co pod wzgl dem wsparcia obsªugi wyj tków. W niektórych j zykach istniej funkcje, które nie mog by wykonane na bª dnych danych lub takie, których wynik nie ró»ni si od tego w przypadku bª du, np. w j zyku C funkcja atoi (konwersja z ASCII do liczby) mo»e zwraca 0 (zero) dla ka»dego wyniku, który nie mo»e zosta przetworzony na poprawn warto±. W takich j zykach programista musi albo wykona sprawdzenie kodu bª du (np. za pomoc pewnej globalnej zmiennej, jak w C errno), albo wykona walidacj warto±ci wej±ciowej. Cz sto± takich r cznych walidacji, b d¹ konieczno± sprawdzania kodów bª du jest odwrotnie proporcjonalna do jako±ci wsparcia obsªugi wyj tków w danym j zyku. Mechanizm wyj tków posiadaj m.in.: SML, Java, JavaScript, Ocaml, Smalltalk, Ruby, Python, C++, C#, Tcl, PHP. Poza niewielkimi ró»nicami syntaktycznymi istnieje tylko kilka stylów obsªugi wyj tków (porównanie w tablicy 1.1). Najbardziej popularne jest inicjowanie wyj tku u»ywaj c specjalnej instrukcji (throw, raise) z podaniem obiektu wyj tku, b d¹ specjalnego typu wyliczeniowego. Zakres kodu, który chcemy kontrolowa rozpoczyna si od 28

31 specjalnego znacznika (zazwyczaj try albo inna konstrukcja rozpoczynaj ca blok jak begin) a ko«czy przy pierwszej klauzuli obsªugi wyj tku (catch, except lub rescue) i je±li jego wykonanie zostanie przerwane wyj tkiem to uruchamia si odpowiednia procedura obsªuguj ca. Mo»na zdeniowa kolejno kilka funkcji obsªugi, a ka»da z nich mo»e okre±la jaki rodzaj wyj tku obsªuguje. Niektóre j zyki wprowadzaj klauzule else oznaczaj c kod, który ma si wykona je±li wyj tek nie nast piª. Bardziej popularna jest natomiast konstrukcja - nally(b d¹ ensure), który oznacza fragment kodu wykonywany zawsze, bez wzgl du na to czy wyst piª wyj tek. Jest ona stosowana przewa»nie do zwolnienia zasobów, które zostaªy uzyskane w kodzie kontrolowanym. C++ Java Python try { i f ( b == 0) throw 1 ; x = a / b ; } catch ( i n t e ) { cout << "b=0"; } try { x = a / b ; } catch ( Exception e ) { System. out. p r i n t l n (" b=0"); } try : x = a / b except Z e r o D i v i s i o n E r r o r : p r i n t "b=0" Tablica 1.1: Przykªad obsªugi wyj tku dzielenia przez zero U»yteczno± Mechanizm obsªugi wyj tków jest bardzo przydatny i u»ywany poprawnie mo»e znacznie uªatwi programowanie oraz zwi kszy niezawodno± aplikacji. Niestety ta konstrukcja mo»e by nadu»ywana prowadz c do nieczytelnego kodu i problemów w utrzymaniu, a ¹le stosowana mo»e powodowa trudne w wykryciu bª dy. Problemy 1. Sterowanie - Obsªuga wyj tków mo»e spowodowa nieoczekiwany przepªyw sterowania. Program mo»e wykonywa si poprawnie, po czym nagle przeskoczy kilka poziomów w gór po stosie wykonania i b dzie kontynuowaª dziaªanie gdzie indziej. 2. Bezmy±lno± - Obsªuga wyj tków cz sto jest nadu»ywana przez lenistwych programistów. Mo»e si zdarzy,»e kiedy nagle co± przestaje dziaªa, zamiast zbada co jest problemem kod zostanie po prostu opakowany w konstrukcj obsªugi, aby zaªata bª d. 3. Zasoby - Obsªu»enie wyj tku w trakcie wykonania bloku kodu przerywa go. Czasami obsªuga wyj tku wymaga zwolnienia zasobów pobranych w kontrolowanym fragmencie kodu, aby nie powodowa wycieków pami ci, ale mo»e by trudno okre±li, które operacje si wykonaªy. Aby mechanizm wyj tków sam nie powodowaª bª dów, funkcje powinny by odpowiednio zaprojektowane, a nie tylko opakowane w obsªug wyj tków. 4. Czas reakcji - Czasami mo»e si zdarzy,»e program wykona funkcj, która wykona du»o pracy, zanim zostanie przerwana przez wyj tek. Cz sto w tych przypadkach mo»na zabezpieczy si prost walidacj danych, przed wykonaniem funkcji, która z tymi danymi na pewno si nie wykona. 29

32 Korzy±ci 1. Niezawodno± - W niektórych aplikacjach przerwanie poprzez bª d jest niedopuszczalne. Niespójno± danych albo wycieki pami ci mog by akceptowane w porównaniu z zatrzymaniem aplikacji. Cz sto przed dostarczeniem wa»nego programu warto zabezpieczy si w globaln obsªug wyj tków, która ukryje wszelkie nieznane bª dy i pozwoli aplikacji dalej pracowa kiedy pojawi si bª d. Procedura ta musi zapisywa informacje o wyst pieniu bª du i mo»e ostrzec u»ytkownika,»e co± poszªo nie tak i dobrym pomysªem jest uruchomienie aplikacji od nowa. Funkcja ta powinna by jednak wyª czona podczas implementacji i testowania aplikacji, w przeciwnym przypadku b dzie ukrywaªa bª dy przed lud¹mi, którzy powinni je naprawi. 2. Osobliwe zdarzenia - Co mo»e si zdarzy przy zapisie pliku na dysk? Zªa nazwa pliku, nie znaleziono katalogu, plik jest tylko do odczytu, katalog jest tylko do odczytu, brak miejsca na dysku, brak zasobów systemu, bª d wej±cia/wyj±cia dysku, dysk nie jest w stacji, dysk przewiercony wiertark... Sprawdzanie ka»dego mo»liwego przypadku bª du ka»dej operacji na pliku byªoby niedorzeczne. Wªa±nie do tego zostaªy zaprojektowane wyj tki. Najpierw nale»y sprawdzi oczywiste rzeczy, jak pusta nazwa pliku, a nast pnie zapisa go wyªapuj c bª dy. Obsªuga wyj tków pozwala utrzyma kod prostym i ci gle radzi sobie stosunkowo dobrze przy obsªudze nieprzewidzianych zdarze«. 3. Ryzykowne wywoªania - Konstrukcje obsªugi wyj tków s dobrym narz dziem do uniezale»nienia aplikacji od bª dów zewn trznych bibliotek. Techniki te s szczególnie polecane je±li biblioteki te mog pó¹niej zosta zmienione, b d¹ istniej w ró»nych wersjach na komputerach u»ytkowników. 4. Szybkie poprawki - Czasami musimy napisa prosty kawaªek kodu, który wykonamy by mo»e tylko raz. Niestety dane na których on operuje zawieraj nieznaczne bª dy przez, które caªy program przestaje dziaªa. Nie chcemy obsªugiwa tych danych wi c operacje na nich opakowujemy w obsªug wyj tków i mo»emy wykona program. W tej i podobnych sytuacjach obsªuga wyj tków sprawdza si bardzo dobrze, gdy» pozwala na szybkie wykonanie prostej operacji. Niestety wielu programistów przenosi tego typu podej±cie na aplikacje bardziej zªo»one. Wnioski Obsªuga wyj tków jest bardzo wa»nym narz dziem programistycznym. Mo»e by, i niestety cz sto jest, u»ywana nieprawidªowo. GOTO byªo kiedy± równie» cenn konstrukcj, ale byªa nadu»ywana, wi c aktualnie nie poleca si jej u»ywania, a dzisiejsze j zyki programowania jej nie posiadaj. Je±li programi±ci b d nadu»ywa obsªugi wyj tków w ten sam sposób, mechanizm ten mo»e zyska zª sªaw i równie» zosta usuni tym. Dobrze jest my±le o obsªudze wyj tków jako o fotelu wyrzucanym w my±liwcach: u»ywa w awaryjnych sytuacjach, nie przy typowych problemach. Mechanizm wyj tków zostaª opracowany w czasach aplikacji na pojedyncze stacje robocze, w okresie kiedy Internet nie byª tak rozwini ty jak aktualnie. Przy projektowaniu wspóªczesnych aplikacji pojawiaj si nowe wyzwania w kwestii strategii obsªugi wyj tków. Ogromne znaczenie w obsªudze wyj tków ma rozpoznanie miejsc, gdzie nie jest mo»liwe naprawienie bª du przy pomocy procedury obsªugi i wymagana jest ludzka interwencja, a nast pnie stworzenie dodatkowych mechanizmów do wspierania takich awarii. 30

33 1.4. Sieci przepªywu pracy TODO: co to sa sieci przeplywu pracy... Koncepcja transakcyjnych sieci przepªywu pracy zostaªa przedstawiona po raz pierwszy w [Shet93], aby wyja±ni znaczenie transakcji w sieciach przepªywu. Poniewa» transakcyjno± okazaª si bardzo wa»nym aspektem ( [Alon97], [Leym00]), powstawaªy mechanizmy dedykowane. Zestawienie wczesnych propozycji mo»na znale¹ w [Cich98]. Od poªowy lat 90-tych mo»na zauwa»y dwa podej±cia do problemu: stworzenie modelu transakcji wspieraj cego sieci przepªywu pracy oraz stworzenie sieci przepªywu pracy zapewniaj cej transakcyjno±. Poni»ej przedstawi niektóre pomysªy z ka»dego nurtu Modele transakcji dla sieci przepªywów ConTract i Spheres of Isolation Model ConTract ( [Wach91], [Wach92], [Wach96], [Reut97]) miaª na celu poª czenie elementów j zyków programowania (deniowanie przepªywu sterowania, iteracje, instrukcje warunkowe, itp.) z przetwarzaniem transakcji. ConTract odpowiada dªugotrwaªej transakcji, b d¹ procesowi i skªada si ze zbioru kroków. Zale»no±ci wykonania pomi dzy krokami okre- ±laj skrypty. Pozwala to na traktowanie pojedynczych kroków jako atomowych jednostek pracy. Dla ka»dego kroku, który musi by kompensowalny, powinien zosta okre±lony niezmiennik wej±ciowy i niezmiennik wyj±ciowy. Pierwszy opisuje warunki jakie musz by prawdziwe, aby rozpocz wykonanie danego kroku. Drugi zawiera warunki, które s speªnione po zako«czeniu wykonania. Je±li warunek z niezmiennika wyj±ciowego kroku i znajduje si w niezmienniku wej±ciowym do kroku i+1, to warunek ten nie mo»e zosta naruszony pomi dzy wykonaniami tych kroków. Jest to proces uzgadniania niezmienników. Kontrola wspóªbie»no- ±ci wykorzystywana przez ConTract jest nazywana szeregowalno±ci niezmienników. Jako rozszerzenie modelu ConTract, powstaª model Spheres of Isolation ( [Schw96]). Podstawowymi elementami s aktywno±ci i tranzycje okre±laj ce warunki uruchomienia aktywno±ci. W przeciwie«stwie do modelu ConTract, ograniczenia(niezmienniki) nie s deniowane na poziomie kroków, a na poziomie obiektów wykorzystywanych przez kroki. Spheres of Joint Compensation W pracy [Leym95] zaprezentowany zostaª model adresowany do pojedynczych procesów. To podej±cie wprowadza kompensacje nie tylko dla pojedynczych aktywno±ci, ale pozwala równie» przypisa jedn aktywno± kompensuj c dla grupy aktywno±ci. Sfera wspólnego kompensowania to wªa±nie taki zbiór czynno±ci, w którym wszystkie aktywno±ci powinny zosta wykonane poprawnie, albo wszystkie powinny zosta skompensowane. Sfery mog si przecina i zawiera w innych sferach. Na potrzeby odwracania u»ywane jest odwracanie wstecz, b d¹ cz ±ciowa kompensacja i powtórzenie bª dnych aktywno±ci. Kontrola wspóªbie»- no±ci nie jest uwzgl dniona w tym modelu. Open Process Management (OPM) OPM ( [Chen96], [Chen97]) ª czy model zagnie»d»onych aktywno±ci z otwartymi transakcjami. Ka»dy proces skªada si z jednej aktywno±ci i/lub bloków. Blok skªada si rekurencyjnie z aktywno±ci lub bloków. Aktywno±ci w procesie s otwarte, oznacza to m.in.»e mog zosta zatwierdzone przed zatwierdzeniem caªego procesu, ale zmiany w nich wykonane s widoczne 31

34 tylko dla innych aktywno±ci w ramach tego samego procesu, a nie na zewn trz. Ma to na celu zwi kszenie wspóªbie»no±ci w porównaniu ze zwykªymi transakcjami zagnie»d»onymi, jednoczenie zapobiegaj c osªabieniu atomowo±ci, które poci ga za sob tradycyjny model otwarty. Mechanizmy odzyskiwania to: odzyskiwanie wstecz z punktami zapisu oraz wykonania alternatywnych bloków (je±li s dost pne). Po bª dzie aktywno±ci wykonywane jest odzyskiwanie dla zawieraj cego j bloku. Je±li nie udaªo si wykona alternatywnych operacji, to bª d jest propagowany w gór hierarchii. WIDE Dwuwarstwowy model transakcji zostaª przedstawiony w pracy [Gref97]. Ni»sza warstwa skªada si z lokalnych transakcji o zagni»d»onej strukturze, zapewniaj cych wªasno±ci ACID ( [Boer98]). Wy»sza warstwa opiera si na sagach, a jej semantyka zostaªa przedstawiona za pomoc teorii grafów ( [Gref01]). Pierwsza modeluje krótkotrwaªe operacje niskiego poziomu, druga za±, dªugotrwaªe procesy biznesowe. X-transaction model Elastyczne podej±cie modelu WIDE zostaªo zaadoptowane w pó¹niejszej pracy przy projekcie CrossFlow ( [Vonk03]). Model X-transaction jest bardziej wszechstronny i mo»e posªu»y przy specycznych przepªywach pracy. Skªada si z trzech poziomów: poziom delegowania, poziom kontraktu i poziom wewn trzny, ka»dy z nich w innym poziomem widoczno±ci. Model reprezentuje caªy proces przepªywu pracy jako transakcj. Procesy wewn trz organizacji mog by podzielone na mniejsze I-kroki, które posiadaj odpowiednie funkcje kompensacji. Procesy mi dzy rmami mog by podzielone na X-kroki skªadaj ce si z jednego lub wi cej I-kroków. Model wprowadza równie» poj cie punktu bezpiecze«stwa, analogicznego do tego w sagach. Wykorzystuj c I-kroki, X-kroki i kompensacje, model pozwala na elastyczne wewn trz- i miedzy- organizacyjne odwracanie Narz dzia Exotica i FlowBack W projecie Exotica [ [Alon96]) zostaªa podj ta próba zarz dzania transakcjami w sieciach przepªywu pracy. Exotica u»ywa kompensacji do wykonywania odwracania operacji, tak jak miaªo to miejsce przy sagach. Mechanizm ten ma statyczn struktur, lecz nie powstaª do niego formalna specykacja. Projekt FlowBack ( [Kiep98]) prezentuje podobne podej±cie. Zarówno w Exotica jak i we FlowBack plany kompensacji s generowane na podstawie opisu sieci przepªywu, a nie jej wykonania. FlowMark IBM FlowMark WFMS ( [Leym94]) u»ywa bazy danych do zapobiegania stratom przy komunikacji, bª dom denicji przepªywu oraz awariom systemów. System nie wspiera jednak biznesowych bª dów. W pracy [Leym95] autorzy przedstawiaj w jaki sposób mo»na zaimplementowa w nim ró»norodne zaawansowane modele transakcji. Jest to jednak w kwestii programisty, aby napisa kompensatory oraz zapewni ich wywoªanie w odpowiednim miejscu. 32

35 Meteor Kompensacja jest cz ±ci narz dzia Meteor ( [Kris95]). W j zyku specykacji sieci WFSL jest specjalne zadanie kompensacji, a system zajmuje si jego uruchomieniem. Niestety nie powstaª kompletny opis algorytmu oraz specykacja formalna. ObjectFlow W narz dziu ObjectFlow ( [Hsu98]) odwracanie na poziomie procesu biznesowego polega na odtwarzaniu stanów. Mechanizm wykonuje przywrócenie danych zapisanych w trakcie wykonania procesu. Nie jest to kompensacja, jednak w pracy autorzy przedstawiaj rozszerzenie, które posiada ograniczone mo»liwo±ci kompensacji. TSME TSME ( [Geor96]) pozwala na zarz dzanie transakcjami poprzez programowanie. Podej±cie jest podobne do modelu ConTract, a opisywanie zale»no±ci mi dzy transakcjami przypomina ACTA. CREW Projekt CREW ( [Kama98]) prezentuje elastyczne podej±cie do kompensowania w sieciach przepªywu pracy. Zarówno wykonanie procesu jak i zale»no±ci kompensacji od kroków procesu s deniowane w specykacji LAWS. Niestety specykacja pozwala na doprowadzenie procesu do ró»nych sytuacji z niejasn semantyk, np. wspóªbie»ne kompensacje i/lub wspóªbie»ne powtórzenia operacji. 33

36 1.5. Usªugi sieciowe Usªugi sieciowe (Web Services) to technologia uªatwiaj ca tworzenie aplikacji komunikuj cych si przez Internet. Pojedyncza usªuga opisuje okre±lon funkcjonalno± biznesow, udost pnian poprzez sie, do wykorzystania przez innych na zasadzie czarnej skrzynki. Polega to na postrzeganiu obiektów/systemów poprzez ich parametry wej±ciowe, wyj±ciowe oraz specykacj wykonywanych czynno±ci, bez wiedzy o ich wewn trznym sposobie dziaªania. Takie podej±cie sprzyja tworzeniu aplikacji z rozproszonych, reu»ywalnych komponentów, których integracja odbywa si przez Internet. Architektura oparta na usªygach(ang. Service Oriented Architecture, SOA) to koncepcja tworzenia oprogramowania. W tej metodologii kªadzie si gªówny nacisk na deniowanie usªug speªniaj cych wymagania u»ytkownika. SOA obejmuje wiele metod organizacyjnych i technicznych, które pozwalaj na lepsze powi zanie zasobów informatycznych z biznesow stron organizacji. Pierwsza fala technologii WS skupiaªa si na deniowaniu komunikacji pomi dzy usªugami. Do przesyªania danych zostaª wybrany format XML ( [XML]). Aby ró»ne technologicznie usªugi mogªy wspóªdziaªa, ich interfejsy musz by opisane za pomoc standardowego j zyka WSDL (Web Services Denition Language) ( [WSDL1.1], [WSDL2.0]). Podstawowymi poj ciami s (WSDL1.1/WSDL2.0): Usªuga (ang. Service/Service) - jest zbiorem funkcji systemu udost pnionych przez sie. Port (ang. Port/Endpoint) - miejsce podª czenia do usªugi. Zazwyczaj jest to zwykªy url. Wi zanie (ang. Binding/Binding) - okre±la styl ª czenia oraz protokóª transportu. Interfejs (ang. PortType/Interface) - zbiór operacji, które mog by wykonane oraz wiadomo±ci przez nie wykorzystywane. Operacja (ang. Operation/Operation) - jest odpowiednikiem wywoªania metody/funkcji w tradycyjnych j zykach programowania. Wiadomo± (ang. Message/N.D.) - przechowuje informacje potrzebne do wykonania operacji. Pojedyncza wiadomo± mo»e si skªada z jednej lub wi cej cz ±ci logicznych. Wiadomo±ci zostaªy usuni te ze specykacji WSDL 2.0, gdzie do opisu parametrów wej±ciowych, wyj±ciowych i bª dów u»ywa si typów XML Schema ( [XMLS DT]). Typy (ang. Types/Types) - opisuj typ danych. Pomimo, i» WSDL pozwala okre±la informacje i wymagania niezb dne do wymiany informacji, jest niewystarczaj cy do opisu procesów biznesowych. Aby w peªni zintegrowa usªugi, które mog pochodzi z ró»nych przedsi biorstw, potrzebny byª model procesu, który b dzie wspieraª dªugotrwaªe wspóªdziaªanie. Z tego powodu powstaªo zapotrzebowanie na j zyki aran»acji(ang. orchestration)/choreograi(ang. choreography) usªug sieciowych. Ich zadaniem jest gromadzenie usªug sieciowych i zarz dzanie nimi zgodnie z reguªami biznesowymi. Proces biznesowy okre±la m.in.: kolejno± wykonania operacji, wspóªdzielone dane przekazywane mi dzy usªugami, uczestników oraz ich role, wspóln obsªug bªedów Business Process Management(BPM) BPM jest zbiorem technologii i standardów do projektowania, wykonywania, zarz dzania i monitorowania procesów biznesowych. Ka»dy krok jest czarn skrzynk i mo»e odpowiada czynno±ci czªowieka, funkcji wewn trznego systemu b d¹ procesowi zaprzyja¹nionej rmy. 34

37 Przez lata BPM zyskaª olbrzymi popularno±. Ponad dekad temu byª u»ywany do zarz dzania sieciami przepªywu pracy, gdzie gªównymi aktorami byli pracownicy, a no±nikami danych - papierowe dokumenty. W dzisiejszych czasach jest technologi integracji przedsi biorstw. Wspóªczesne procesy aran»uj wspóªdziaªania zªo»onych systemów oraz s zdolne do komunikacji i konwersacji z procesami innych rm zgodnie z okre±lonymi wytycznymi. Technologie i standardy Niestety BPM byª cz sto u»ywany bez zrozumienia lub wykorzystywany niepotrzebnie. Sytuacji nie poprawia mnogo± standardów dla BPM oraz usªug sieciowych (zestawienie w tablicy 1.2). Standard Organizacja Typ Business Process Execution Organization for the Advancement J zyk wykonywania Language (BPEL) of Structured Information Standards (OASIS) Business Process Schema Specication OASIS Choreograa procesów (BPSS) Business Process Modeling Business Process Management Standard notacji Notation (BPMN) Initiative (BPMI) Business Process Modeling BPMI J zyk wykonywania Language (BPML) Business Process Query Language (BPQL) BPMI Interfejs zarz dzania i monitorowania Business Process Semantic BPMI Metamodel procesu Model (BPSM) Business Process Extension BPMI Rozszerzenie BPEL do obsªugi Layer (BPXL) transakcji, czynno±ci ludzkich, reguª biznesowych Workow Reference Model Workow Management Coalition Wzorzec architektury (WfMC) XML Process Denition Language WfMC J zyk wykonywania (XPDL) Workow API (WAPI) WfMC Zarz dzanie i monitorowanie Workow XML (WfXML) WfMC Choreograa procesów Business Process Denition Object Management Group J zyk wykonywania oraz Metamodel (BPDM) (OMG) metamodel procesu UML Activity Diagrams OMG Standard notacji Business Process Runtime Interface (BPRI) OMG Zarz dzanie i monitorowanie Web Services Choreography World Wide Web Consor- Choreograa procesów Interface (WSCI) Web Services Choreography Description Language (WS- CDL) Web Services Conversation Language (WSCL) tium (W3C) W3C W3C 35 Choreograa procesów Choreograa procesów

38 Standard Organizacja Typ XLANG Microsoft J zyk wykonywania Web Services Flow Language IBM J zyk wykonywania (WSFL) Tablica 1.2: Cz ± dost pnych aktualnie standardów Niektóre z powy»szych standardów s konkurencyjne, a cz ± si uzupeªnia. Chc c skorzysta z którego± z nich, przy pierwszym zetkni ciu, trudno jest si odnale¹ i zdecydowa. W ksi»ce [Have05] autor pokazuje, jak na podstawie tych standardów mo»na utworzy idealn architektur do obsªugi procesów biznesowych (rysunek 1.9). Rysunek 1.9: Obsªuga procesów biznesowych Jej ksztaªt opiera si na modelu stworzonym przez WfMC ( [WfMC]), najdojrzalszej z grup standaryzuj cych BPM. Skupia ona w sobie wiele cech platform integracyjnych takich rm jak: IBM, BEA, Oracle, Tibco, SeeBeyond i Vitria. Zawiera ona BPEL, BPMN oraz WS-CDL, gdy» s to najlepsze podej±cia do, odpowiednio, wykonywania, projektowania i choreograi - trzech zasadniczych cz ±ci BPM. Sercem systemu jest silnik wykonuj cy procesy opisane w j zyku BPEL - najpopularniejszym standardzie BPM b d cym najlepszym z j zyków wykonywania. Procesy s projektowane przez biznesowych i technicznych analityków przy u»yciu gracznych edytorów wspieraj cych wizualne diagramy przepªywu w j zyku BPMN - najlepszym z gracznych j zyków 36

39 BPM. Z opisu gracznego generowany jest kod BPEL (przykªad przepisania w [BPMN2BPEL]). Wspóªdziaªanie z zewn trznymi systemami opiera si zazwyczaj o usªugi sieciowe, którymi zarz dzaj narz dzia choreograi j zyka WS-CDL. Specykacja ta w przedstawionej architekturze sªu»y dodatkowo do generowania bazowych modeli BPMN, które odzwierciedlaj niezb dn komunikacj procesu z wykorzystywanymi usªugami zewn trznymi. Publikacje o WS-CDL sugeruj generowanie BPEL, a nie BPMN, lecz w tej architekturze krok po±redni jest potrzebny do dalszego projektowania procesu. Za obsªug bª dów odpowiada silnik wykonywania procesu. Jako,»e BPEL jest uwa»any za najlepszy ze standardów, poni»ej przedstawi go dokªadniej. Inne technologie stosuj podobne podej±cie. BPEL TODO: jakis obrazek?? It supports the modeling of business processes as a network of activities. This network of activities, the process model, is constructed as a directed, acyclic, weighted, colored graph. The nodes of the graph represent the activities, which dene the individual tasks that need to be carried out. In general, each of the activities is associated with a piece of code that implements the appropriate task. The edges of the graph, the control connectors, describe the potential sequence of execution of the activities. Denition of the process graph is via a graphical editor or a ow denition language, such as Business Process Execution Language for Web Services (BPELWS). BPEL powstaª jako poª czenie specykacji WSFL od IBM oraz XLANG od Microsoft. Struktura tego j zyka zawiera aktywno±ci, które mog by proste (np. odebranie wiadomo±ci) lub zªo»one (np. przeplot sekwencji wspóªbie»nych aktywno±ci). Dla ka»dej z nich mo»liwe jest zdeniowanie obsªugi bª dów oraz kompensatora. Aktywno±ci s grupowane (jedna aktywno± to te» grupa) w zakresy(ang. scope) i obsªugiwane wspólnie przy napotkaniu bª du. Bª dy maj ró»ne typy i mog powstawa automatycznie, np. przy odebraniu niepoprawnie sformatowanych danych. Mog by równie» deniowane przez programistów w aktywno±ciach, np. informuj c o braku towaru w magazynie. W przypadku wyst pienia bª du w jednym procesie, mo»liwa jest jego propagacja do innego procesu. Bª dy mog równie» zawiera powi zane dane. Kiedy wyst pi bª d, uruchamiana jest jego obsªuga z najbardziej lokalnego zakresu, a zwi zane w nim aktywno±ci s automatycznie przerwane. Bez wzgl du na to jak bª d zostanie obsªu»ony, zakres jest traktowany jako zako«czony niepoprawnie. Je±li programista nie zapewni obsªugi bª du okre±lonego typu to wykonana zostanie domy±lna funkcja obsªugi. Dziaªa ona podobnie do obsªugi w sagach: dla ka»dego poprawnie zako«czonego podzakresu zawartego w obsªugiwanym zakresie, uruchamia odpowiedni kompensacj w kolejno±ci odwrotnej od ich chronologicznego wykonania. Nast pnie propaguje bª d do zakresu zawieraj cego obsªugiwany zakres. Je±li zakres nie posiada kompensatora, to domy±lna kompensacja polega na wywoªaniu w odwrotnej kolejno±ci kompensatorów dla ka»dego poprawnie zako«czonego zawartego podzakresu. Kompensator dla zakresu ma dost p do zapisanego stanu danych z pocz tku jego wykonania. S to dane (kontenery) przechowywane przez silnik sieci przepªywu, a nie dane zapisane do baz danych przez aktywno±ci. Silnik posiada kontrol wspóªbie»no±ci dost pu do kontenerów. W ka»dym zakresie mo»na okre±li, czy ma by ni obj ty. Kompensatory s wykonywane jedynie dla aktywno±ci, które ju» si wykonaªy oraz s uruchamiane tylko przy obsªudze bª dów. Nie ma mo»liwo±ci uruchomienia mechanizmu w kodzie przy poprawnym dziaªaniu aktywno±ci. 37

40 Transakcje Równie» w ±rodowisku usªug sieciowych zaistniaªa potrzeba zawi kszenia spójno±ci i niezawodno±ci procesów biznesowych. Zachowanie spójnego stanu danych u ró»nych stron zaanga»owanych w proces jest skomplikowane: 1. W jednej transakcji mo»e uczestniczy wiele usªug, a komunikacja mo»e w ka»dym momencie zosta przerwana. 2. Usªugi mog by lu¹no powi zane, przez co nie jest mo»liwe wzajemne blokowanie zasobów. 3. Usªugi mog pracowa na ró»nych technologicznie platformach. 4. Usªugi mog by asynchroniczne, a ich odpowiedzi przychodzi w dowolnym momencie. Nie istnieje»aden dojrzaªy mechanizm transakcji, który byªby uwa»any powszechnie za standard. Poni»ej przedstawi kilku kandydatów. S to specykacje uzupeªniaj ce j zyki wykonania i choreograi procesów o protokoªy zapewniaj ce transakcyjne przetwarzanie. Business Transaction Protocol (BTP) Stworzony przez OASIS ( [OASIS]) protokóª Business Transaction Protocol ( [BTP]) nie jest zaprojektowany jedynie do usªug sieciowych. Jest to protokóª dwufazowy. W pierwszej, wszyscy uczestnicy transakcji musz si przygotowa, np. musz zapewni,»e zadanie mo»e zosta zatwierdzone b d¹ wycofane przy wyst pieniu bª dów. W drugiej fazie, koordynator transakcji rozsyªa komunikat potwierdzaj cy lub przerywaj cy do uczestników. Web Services Transactions (WS-Tx) Z inicjatywy Microsoft, IBM i BEA powstaªa specykacja Web Services Transactions ( [WS-TX]), której utrzymaniem zajmuje si obecnie OASIS. W jej skªad wchodz : WS-Coordination (WS-C) - opisuje mechanizmy sªu» ce do koordynowania wielu usªug uczestnicz cych we wspólnej aktywno±ci. WS-C skªada si z dwóch cz ±ci: 1. generycznej, udost pniaj cej uczestnikom wspólny kontekst oraz pozwalaj cej na wª czenie si w transakcj kontrolowan przez koordynatora, 2. szczegóªowej, okre±laj cej protokóª jako typ koordynacji. Korzystaj c z cz ±ci genetycznej, na bazie WS-C mog powstawa protokoªy transakcji, które s jej skonkretyzowaniem. WS-AtomicTransaction (WS-AT) - protokóª transakcji atomowych, który mo»e by u»ywany przy krótkotrwaªych transakcjach pomi dzy ±ci±le powi zanymi uczestnikami o du»ym zaufaniu. Bazuje na 2PC i ma dwa warianty: 1. nietrwaªy 2PC, dla uczestników zarz dzaj cych nietrwaªymi zasobami (np. pami podr czna), 2. trwaªy 2PC, dla uczestników zarz dzaj cych trwaªymi zasobami (np. bazy danych). 38

41 WS-BusinessActivity (WS-BA) - protokóª do budowania aplikacji wykorzystuj cych dªugotrwaªe, lu¹no powi zane, rozproszone aktywno±ci, dla których tradycyjny model ACID nie jest odpowiedni. WS-BA bazuje na rozszerzonych modelach transakcji, wi c wyniki aktywno±ci mog by widoczne przed zako«czeniem caªej transakcji i mog zosta odwrócone poprzez kompensacje. Oddzielenie WS-Coordination od konkretnych protokoªów transakcji ma dwie podstawowe zalety: 1. Funkcje u»ywane do koordynacji mog by wykorzystane do celów innych ni» zarz dzanie transakcjami. 2. Istnieje mo»liwo± wykorzystania innych protokoªów ni» WS-AT i WS-BA. WS Composite Application Framework (WS-CAF) OASIS dysponuje jeszcze jedn specykacj - WS Composite Application Framework ( [WS-CAF]), która powstaªa z inicjatywy SUN, Oracle i Arjuna. Podobnie jak WS-Tx skªada si z kilku cz ±ci: Web Service Context (WS-Context) - mechanizm do prostego zarz dzania kontekstem transakcji. Web Service Coordination Framework (WS-CF) - opisuje zachowania koordynatora, do którego zgªaszaj si usªugi, aby zosta wª czone do kontekstu i otrzymywa wyniki. Mo»e sªu»y jako baza do tworzenia protokoªów transakcji. Web Services Transaction Management (WS-TXM) - skªada si z trzech ró»nych protokoªów: dwufazowego zatwierdzania, dªugotrwaªych akcji oraz przepªywu procesów biznesowych. Implementacja WS-CAF mo»e odbywa si przyrostowo, w zale»no±ci od wymaga«. Zaczynaj c od WS-Context uzyskamy dost p do prostego zarz dzania kontekstem, przydatnego w prostych aplikacjach. Dodaj c WS-CF otrzymamy dodatkowe metody zarz dzania kontekstem oraz zapewnienie dostarczania wiadomo±ci. Z WS-TXM dostaniemy ró»ne protokoªy odzyskiwania. Gªównym celem poª czenia tych cz ±ci jest zapewnienie kompletnego rozwi - zania zarz dzania transakcjami, wspieraj cego ró»ne architektury oraz modele przetwarzania. Porównanie W [Litt03] zostaªo przedstawione porównanie BTP i WS-Tx. Autorzy pokazali w jaki sposób te dwie specykacje próbuj rozwi za problem transakcyjno±ci w usªugach sieciowych. Przedstawili list za i przeciw ka»dego rozwi zania. Wnioskiem z tego zestawienia jest to,»e specykacje ró»ni si w niektórych kluczowych kwestiach, np. wspóªdziaªanie transakcji. Dodatkowo BTP mo»e wymaga modykacji istniej cego oprogramowania. Autorzy zwracaj uwag na to,»e cz sto pod lu¹no powi zanymi usªugami sieciowymi w rzeczywisto±ci istnieje silnie powi zana infrastruktura pojedynczej organizacji. W takim przypadku lepiej spróbowa skorzysta z transakcji ACID, zamiast zast powa je nowymi modelami dla usªug sieciowych. Inne porównanie mo»na znale¹ w [Krat04]. Raport zawiera szczegóªowe omówienie trzech wymienionych specykacji oraz podkre±la ró»nice mi dzy nimi. Autor podsumowuje prac zauwa»aj c brak jednego powszechnego standardu, który pozwoliªby okre±la wspóªdziaªania 39

42 zarówno na poziomie usªug jak i na poziomie biznesowym. Sugeruje zintegrowanie rozwi za«do specykacji WS-CAF. Autorzy pracy [Jin03] twierdz,»e BTP jest najodpowiedniejszym kandydatem na standard transakcji w Internecie. Przedstawiaj model Agent Based Transactional (ABT) bazuj cy na usªugach sieciowych. Twierdz,»e u»ycie technologii agentowej do zarz dzania transakcjami jest dobrym wyborem w ±rodowisku usªug sieciowych. ABT mo»e elastycznie wybiera alternatywnych uczestników, aby zmniejszy szanse na odwrócenie i kompensacje. Jest to nowatorskie poª czenie technologii agentowej i usªug sieciowych, jednak jest ci gle we wczesnej fazie rozwoju. TRY-CANCEL/CONFIRM (TCC) Zupeªnie inne podej±cie przyj li autorzy rozwi zania zwanego TCC ( [TCC]). Rozró»niaj oni dwa scenariusze wykonywania kompensacji transakcji biznesowych. Pierwszy jest okre±lany jako bezstanowy. Przykªadem mo»e by operacja zakupienia akcji na gieªdzie. Gdy po operacji zorientujemy si,»e popeªnili±my bª d mo»liwe jest odwrócenie poprzez ich sprzedanie. Jak wiadomo, poniewa» ceny akcji mogªy ulec zmianie, na sprzeda»y mo»na straci lub zarobi. Kompensacja jest oddzieln transakcj biznesow, a dostawca usªug sieciowych (dom maklerski) nie musi martwi si o zapewnianie odwracania. Takie procesy nadaj si idealnie do modelowania przy pomocy technologii przepªywu pracy jak BPEL. Zakup akcji mo»e by jednym z kroków procesu. Silnik wykonuj cy proces zapewni,»e je±li transakcja zostanie przerwana, wykona si zdeniowana kompensacja, czyli sprzeda» akcji. Dla dostawcy usªugi zakupu akcji nie ma znaczenia jak dªugo b dzie trwaª proces i nie jest potrzebne powi zanie zakupu i sprzeda»y. W drugim scenariuszu, kompensacja jest cz ±ci podstawowej transakcji. Przykªadem jest zakup biletów lotniczych z przesiadk. Je±li uda nam si zakupi jeden bilet, a nast pnie nie znajdziemy dalszego poª czenia, idealnie byªoby, aby pierwsza rezerwacja zostaªa anulowana. Przy takich transakcjach autorzy proponuj u»ycie dwufazowego protokoªu TCC. Dla scenariusza rezerwowania miejsca w samolocie, mo»emy okre±li trzy stany rezerwacji: oczekuj ca, zatwierdzona i anulowana. Operacja TRY odpowiada normalnej biznesowej operacji, np. zarezerwowanie miejsca. Jest to pierwsza faza. Z biznesowego punktu widzenia transakcja jest w stanie oczekuj cy, gdy» nie jest jeszcze ostateczna. Miejsce to nie mo»e ju» by nikomu przydzielone, ale informacja o tej rezerwacji nie mo»e pojawia si w systemach raportowych i ksi gowych. Dodatkowo dobrze jest ustawi limit czasu na jej potwierdzenie, po którym rezerwacja zostanie anulowana. W drugiej fazie mo»liwe jest wykonanie operacji CANCEL lub CONFIRM. CANCEL odpowiada mo»liwemu anulowaniu transakcji przez u»ytkownika lub po przekroczeniu limitu czasu. Odwrócenie wykorzystuje mechanizmy kompensacji. CONFIRM zatwierdza transakcje, jest to sygnaª,»e rezerwacja powinna by utrwalona, a klient powinien zosta obci»ony kosztami. Zastosowanie tego mechanizmu wymaga od dostawcy usªug utworzenia dodatkowych operacji anulowania i zatwierdzania, oraz odpowiedniego obsªu»enia stanów po±rednich. Aczkolwiek tego typu mechanizmy cz sto istniej w systemach informatycznych. Okre±lanie limitu czasu jest bardzo popularne i je±li odpowiednia obsªuga ju» istnieje, wystarczy j tylko udost pni. Dodatkowo dostawcy usªug mog udost pnia operacje anulowania, gdy» wol sami kontrolowa ten mechanizm, aby nie by zale»nym od zewn trznych systemów. Zarz dca transakcji w TCC sam obsªuguje koordynacj zada«i przesyªanie komunikatów CANCEL i CONFIRM. Przerzucenie odpowiedzialno±ci za obsªug bª dów na protokóª i wykorzystanie kompensacji zaimplementowanych w usªugach znacznie upraszcza model procesu. Zamiast samemu implementowa zªo»one mechanizmy zarz dzania transakcjami, mo»na sku- 40

43 pi si po prostu na poprawnej ±cie»ce procesu. Zarz dca TCC b dzie ±ledziª kroki, które wymagaj kompensacji i wykonywaª j przy bªedach Podsumowanie Architektura SOA sprzyja automatyzowaniu procesów lecz nie wspiera w peªni zada«wykonywanych przez ludzi. Wiele procesów biznesowych mo»e wymaga ludzkiej r ki m.in. z powodów prawnych. Automatyzowanie BPM jest dopiero na wczesnym stadium ª czenia z SOA, która ma przyspieszy przepªywy pracy. Niestety zadania wymagaj ce ludzkiego dzia- ªania mog zmniejszy efektywno±. Minie zapewne du»o czasu zanim to si zmieni, gdy» ryzykowne mo»e by peªne zautomatyzowanie procesów. 41

44 1.6. Obecny kierunek rozwoju Aktualnie mo»na zaobserwowa dwa gªówne kierunki rozwoju technologii transakcyjno±ci Pami transakcyjna Pami transakcyjna to mechanizm uªatwiaj cy programowanie wspóªbie»ne. Pozwala zapewni,»e pewna grupa instrukcji odczytu/zapisu zostanie wykonana atomowo. Jest to mechanizm kontroli wspóªbie»no±ci analogiczny do transakcji bazodanowych, który kontroluje dost p do wspóªdzielonej pami ci. Kontrola takiego dost pu jest cz sto najwi kszym problemem przy aplikacjach wykorzystuj cych wielordzeniowe procesory. Celem systemów pami ci transakcyjnej jest przezroczyste dla programisty kontrolowanie bloków kodu, które powinny mie wªasno±ci transakcji: atomowo±, spójno± i izolacj. Pami transakcyjn mo»na zaimplementowa sprz towo, aplikacyjnie albo jako poª czenie obydwu technik. Zestawienie mo»na znale¹ w [Laru06]. Sprz towa pami transakcyjna mo»e wymaga modykacji procesora, pami ci podr cznej oraz protokoªów szyny danych. Technika aplikacyjna zapewnia semantyk transakcji w przypadku u»ycia odpowiednich bibliotek dla j zyków programowania i wymaga minimalnych modykacji sprz towych (zazwyczaj dost pno± atomowych operacji porównania i zamiany) Siatki transakcji Przetwarzanie siatkowe jest form programowania rozproszonego. Polaga na koordynowaniu wspólnych zasobów obliczeniowych poprzez Internet. Pozwala to na olbrzymie zwi kszenie mocy obliczeniowej do wielko±ci dost pnej do tej pory jedynie dla du»ych korporacji z farmami wyspecjalizowanych serwerów. Technologia cieszy si olbrzymi popularno±ci od momentu jej zaistnienia. Powstawaªo wiele projektów, a najwi kszym z nich jest CoreGRID ( [CoreGRID]). Badania skupiªy si jednak gªównie na tworzeniu infrastruktury, a mniejsz wag przykªada si do transakcji w tej architekturze. Powstaªo jednak kilka ciekawych prac dotycz cych tego tematu. Stworzone w Europie TM-RG (GGF Transaction Management Research Group) stara si zaimplementowa transakcje w systemach siatkowych na bazie usªug sieciowych. Do tej pory nie powstaªy jednak»adne publikacje tej organizacji. Na Uniwersytecie Jiang Tong w Szanghaju istnieje jednostka pracuj ca nad architektur GridTP. Bazuje ona na platformie Open Grid Services Architecture (OGSA) oraz na modelu X/Open DTP ( [Qi04]). Autorzy twierdz,»e ich architektura jest efektywnym sposobem na wykorzystanie istniej cych, autonomicznie zarz dzanych baz danych w przetwarzaniu siatkowym. W publikacji [Turk05] autorzy prezentuj najwa»niejsze problemy przy wª czaniu transakcji w przetwarzanie siatkowe. Proponuj protokóª zapewniaj cy poprawne wykonanie wspóªbie»nych aplikacji bez globalnego koordynatora, realizuj cy idee rozproszonych transakcji. W zaprezentowanym podej±ciu zale»no±ci mi dzy transakcjami s obsªugiwane przez same transakcje, czyli do poprawnego wykonania nie jest potrzebna peªna wiedza o uczestnikach globalnej transakcji. Pomysª jest innowacyjny, poniewa» do nowych problemów wykorzystuje sprawdzone techniki, m.in.: kryteria odtwarzalno±ci(ang. recoverability criterion), testowanie grafów serializacji(ang. serialization graph testing), cz ±ciowe odwracanie. Z rozwojem technologi przetwarzania siatkowego, co raz cz ±ciej b dzie si pojawiaªa potrzeba zapewniania niezawodno±ci przy koordynowaniu i komunikacji miedzy w zªami. 42

45 1.7. Specykacje formalne Niestety transakcjie dªugotrwaªe oraz kompensacje s ró»nie interpretowane przez autorów ró¹nych narz dzi. Notacja dost pnych specykacji jest cz sto zdeniowana jedynie poprzez opis sªowny. Aby poprawnie zamodelowa procesy oraz móc wnioskowa na temat ich wªasno±ci, potrzebne s narz dzia matematyczne. Przez lata powstaªo kilka propozycji, które mo»na podzieli na dwie grupy: j zyki modelowania kompensowalnych przepªywów i rozszerzenia algebr procesów. Pierwsza to propozycje bazuj ce na istniej cych standardach jak BPEL i próbuj ce modelowa procesy w zbli»ony sposób. Druga grupa zawiera rozszerzenia istniej cych algebr procesów, które s niezale»ne od technologii. Niestety,»adna z propozycji nie pozwala na modelowanie zªo»onego procesu, który daªoby si pó¹niej ªatwo zaimplementowa J zyki modelowania kompensowalnych przepªywów Do pierwszej grupy zaliczaj si m.in. STaC( [Butl00], [Butl04]), rachunek sag(ang.saga calculus)( [Brun05]), kompensowalne CPS(ang.compensating CSP, ccsp)( [BuHo04]). Ich wspóln cech jest u»ywanie atomowych akcji jako skªadowych procesu, oraz ich kompensacji. Ró»ni si gªównie: wspieranymi konstrukcjami, np. czy pozwalaj na rekurencj, czy wspóªbie»ne procesy mog by synchronizowane, czy istniej mechanizmy zatwierdzania, zaªo»eniami o akcjach atomowych: czy zawsze wykonuj si bezbª dnie, rodzajem semantyki: operacyjna czy oparta o ±lady. J zyk STaC jest inspirowany na technologii BPBeans ( [Ches01]), która pozwala budowa aplikacje jako zagnie»d»on hierarchi procesów biznesowych. Dekompozycja na podprocesy oraz kompensacje s zbli»one do tych zaproponowanych w sagach. STaC jako j zyk modelowania przepªywów posiada operatory umo»liwiaj ce jawne uruchomienie, b d¹ odrzucenie kompensacji. Do wykonywania procesu u»ywa centralnego koordynatora. W ccsp oraz rachunku sag przyj to podobn koncepcj. Porównanie dwóch ostatnich mo»na znale¹ w [BBFHMM05] Rozszerzenia algebr procesów Istnieje wiele modeli matematycznych sªu» cych do opisu programów. Dlaczego wi c dla dªugotrwaªych procesów wymy±la nowy, a nie skorzysta z gotowego, sprawdzonego przez lata? Tak jak z wynalezieniem samochodu: ªatwiej wstawi silnik do zaprz gu, ni» wymy±la caª konstrukcj od pocz tku. Tabela 1.3 prezentuje zestawienie najpopularniejszych modeli oraz cech wymaganych przy transakcyjnych procesach. Model Zupeªno± Kompozycyjno±bie»no±ci Model wspóª- Model Obsªuga zasobów bª dów Maszyna tak nie nie tak nie Turinga Rachunek tak tak nie nie nie Lambda Sieci Petriego tak nie tak tak nie 43

46 Model Zupeªno± Kompozycyjno±bie»no±ci Model wspóª- Model Obsªuga zasobów bª dów CCS tak tak tak nie nie π-calculus tak tak tak tak nie Tablica 1.3: Zestawienie modeli Niestety, jak wida w tabeli,»aden model nie posiadaª wsparcia obsªugi bª dów i mechanizmów transakcji. Z zestawienia wynika,»e najbardziej odpowiedni wybór bazy do tworzenia modelu to algebra procesów π-calculus ( [PiCalc]) (lub podobna), która pokrywa najwi cej wymaga«. Zauwa»yli to równie» dostawcy oprogramowania i opierali si na niej przy tworzeniu swoich narz dzi choreograi, np. XLANG i BPEL. πt-calculus W pracy [Bocc03] zostaªa zaprezentowana algebra πt-calculus, zainspirowana narz dziem BizTalk ( [BizTalk]). Jest to rozszerzenie asynchronicznej wieloargumentowej π-calculus ( [Sang01]) o notacje transakcji. Komensacje ka»dej transakcji s statycznie deniowane. cjoin calculus Algebra cjoin calculus ( [Brun04]) rozszerza Join calculus ( [Four96]) o wyra»enia reprezentuj ce transakcje. Podobnie jak w πt-calculus, kompensacje s deniowane statycznie. Zako«czone transakcje nie mog by kompensowane. webπ Laneve i Zavattaro zdeniowali algebr zwan webπ ( [Lane05]) b d c rozszerzeniem asynchronicznej wieloargumentowej π-calculus o konstrukcje transakcji z czasem. Transakcje bez czasu s dost pne w algebrze webπ zaproponowanej w pracy ( [Mazz06]). Niestety w tych algebrach brakuje wsparcia dla transakcji zagnie»d»onych. S one w nich prezentowane jako pªaskie transakcje. Dodatkowo obsªuga bª dów w takich strukturach musi by r cznie oprogramowana, np. w specykacji bª d transakcji nie powoduje anulowania podtransakcji. Tak jak w cjoin calculus, zako«czone transakcje nie mog by kompensowane oraz tak jak w πt-calculus kompensacje s deniowane statycznie. Algebra zakªada,»e transakcje s jednoznacznie identykowane, ale nie posiada operatorów, aby zapewni to formalnie. SOCK Kolejna propozycja( [Guid08]) to rozszerzenie algebry SOCK( [Guid06]), zainspirowanej przez WSDL i BPEL. Algebra posiada konstrukcje pozwalaj ce na dynamiczne deniowanie kompensacji. Oznacza to,»e obsªuga bªedów i kompensacja mog zale»e od wykonania procesu. Tak jak w webπ, algebra jedynie zakªada rozró»nialno± transakcji. dcπ-calculus Autorzy pracy [Vaz09] przedstawiaj kolejn propozycj dynamicznego modelowania odtwarzania. Bazuje ona na asynchronicznej wieloargumentowej π-calculus. Jej skªadnia przypomina webπ, ale tu podobie«stwa si ko«cz. Gªówne koncepcje zawarte w tej algebrze to: kompensowalne aktywno±ci, zakresy kompensacji, dynamiczne i statyczne deniowanie 44

47 kompensacji i zagnie»d»one procesy. Zako«czone transakcje mog by kompensowane, a ich rozró»nienie jest zapewniane poprzez okre±lanie typów. Podsumowanie W tabeli 1.4 znajduje si zestawienie najwa»niejszych cech przedstawionych modeli. Model Asynchroniczno± Kompensacje Deniowanie kompensacji Zako«czone transakcje Zagnie»d»one bª dy πt-calc. tak statyczne niejawne niekompensowalne tak cjoin tak statyczne niejawne niekompensowalne tak Webπ tak statyczne niejawne niekompensowalne nie Webπ tak statyczne niejawne niekompensowalne nie SOCK nie dynamiczne jawne kompensowalne tak dcπcalc. tak dynamiczne niejawne kompensowalne tak i statyczne Tablica 1.4: Zestawienie rozszerzonych algebr procesów Niestety okazuje si,»e w rzeczywisto±ci zbyt ci»ko jest poª czy te algebry z faktyczn implementacj, gdy» s albo zbyt proste do potrzeb biznesowych, albo zbyt skomplikowane, aby daªo si zaimplementowa je oraz zamodelowane w nich procesy. Sytuacj pogarsza równie» fakt,»e w ka»dej z algebr kompensacje s uruchamiane w dowolnej kolejno±ci, a taki niedeterminizm jest cz sto niedopuszczalny w biznesowych aplikacjach. 45

48

49 Rozdziaª 2 System obªugi cash pooli Po przeanalizowaniu ró»norodnych rozwi za«obsªugi bª dów, przedstawi dziedzin systemu, którego b dzie dotyczyªa dalsza cz ± pracy Cash pool Zarz dzanie pªynno±ci Do gªównych zada«osoby odpowiedzialnej za zarz dzanie nansami du»ego przedsi biorstwa lub holdingu (grupy przedsi biorstw powi zanych kapitaªowo) nale»y pozyskiwanie nowych ¹ródeª nansowania, d»enie do minimalizacji kosztów oraz maksymalizacja korzy±ci z posiadanej gotówki. Szczególnie cenione s oszcz dno±ci, które nie pogorsz jako±ci funkcjonowania przedsi biorstwa oraz produktów i usªug przez niego oferowanych. Wykorzystanie kapitaªu obcego w znacznym stopniu wpªywa na wzrost kosztów nansowych. Najbardziej popularnym ¹ródªem pozyskania ±rodków na nansowanie dziaªalno±ci operacyjnej jest krótkoterminowy kredyt bankowy. Sªu»y on jako uzupeªnienie czasowego niedoboru ±rodków lecz skutkuje konieczno±ci ponoszenia kosztów zwi zanych z oprocentowaniem. Du»e przedsi biorstwa cz sto maj rozbudowan i skomplikowan struktur organizacyjn. Jednostki wchodz ce w ich skªad korzystaj ce w ró»nym stopniu z nansowania obcego. Niektóre z nich posiadaj wolne ±rodki ulokowane na rachunkach depozytowych, inne bywaj zadªu»one. Ró»nica w oprocentowaniu lokat i kredytów jest znaczna i pokrywa koszty obsªugi oraz jest ¹ródªem wynagrodzenia banku. Banki podj ªy prób wykorzystania tej sytuacji i zdobycia wi kszej liczby klientów opracowuj c usªug umo»liwiaj c bardziej efektywne zarz dzanie pªynno±ci - cash pooling ([Kopr09a], [Kopr09b]) Zasada dziaªania Dziaªanie usªug cash poolingowych opiera si na grupowaniu rachunków przedsi biorstwa b d¹ grupy w celu lepszego wykorzystania nadwy»ek ±rodków pieni»nych. Wyró»niamy dwa podstawowe typy: cash pool wirtualny (zwany tak»e nierzeczywistym lub notional cash pool) - jest struktur, w której nie wyst puj zyczne transfery pieni»ne pomi dzy rachunkami uczestników, cash pool rzeczywisty (zwany tak»e realnym lub efektywnym) - ±rodki pieni»ne s zycznie przelewane pomi dzy rachunkami. 47

50 Pierwszy rodzaj polega na kalkulowaniu odsetek na podstawie zbilansowanego salda zadªu»enia (sumy ±rodków na rachunkach), bez konieczno±ci dokonywania transferów pomi dzy rachunkami. Odsetki s oparte na sumie sald dodatnich i ujemnych, a nie na saldach poszczególnych rachunków. Stany ±rodków na poszczególnych rachunkach uczestnicz cych pozostaj bez zmian. Drugi typ przewiduje zyczny transfer ±rodków pieni»nych na rachunek gªówny grupy kapitaªowej ze ±rodków zgromadzonych na ró»nych kontach spóªek, a nast pnie rozdzielenie ich w zale»no±ci od zapotrzebowania rachunków danej spóªki. Dzi ki temu mo»liwa jest kompensacja niedoborów jednych podmiotów nadwy»kami innych. Taka transakcja ma charakter zwrotny, gdy» najcz ±ciej jest dokonywana pod koniec dnia, najwcze±niej po ostatniej sesji bankowej, na której dokonuje si przelewów bankowych, by w nast pnym dniu w porach rannych zwróci ±rodki na poszczególne rachunki spóªek. Przykªad na rysunku Rysunek 2.1: Przykªad wykonania kompensacji ±rodków w ko«cu dnia na rachunkach struktury cash pool rzeczywisty Cash pooling stanowi ofert skierowan i konstruowan specjalnie wedªug potrzeb danego przedsi biorstwa lub grupy kapitaªowej. Przewa»nie w ofercie banku istnieje kilka produktów, które mog zosta odpowiednio skongurowane na potrzeby danego klienta poprzez m.in.: okre±lenie rachunków w strukturze, harmonogramy wykonania, generowanie raportów. Czasami jednak zdarza si,»e w celu obsªu»enia nowego klienta potrzebne jest opracowanie nowego typu usªugi, poniewa» jedynie struktura uwzgl dniaj ca specyk danej jednostki oraz dostosowana do polskich przepisów prawnych, pozwala na usprawnienie zarz dzania ±rodkami rmy. 48