Uniwersytet Warszawski Wydziaª Matematyki, Informatyki i Mechaniki Sebastian Tomaszewski Nr albumu: 219712 Mechanizmy reagowania na wyj tkowe sytuacje w dªugotrwaªych procesach biznesowych. Rozwój, porównanie i zastosowanie w systemie obsªugi cash pooli. Praca magisterska na kierunku INFORMATYKA Praca wykonana pod kierunkiem dra Piotra Chrz stowskego-wachtla Instytut Informatyki wrzesie«2009
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
Streszczenie 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
Spis tre±ci Wprowadzenie....................................... 5 1. Historia - 25-30 stron................................. 7 1.1. Transakcyjno±................................... 7 1.1.1. Pocz tki transakcji............................. 7 1.1.2. ACID.................................... 7 1.2. Rozwój modeli transakcji............................. 10 1.2.1. Pªaski model transakcji.......................... 10 1.2.2......................................... 12 1.2.3......................................... 13 1.2.4. OLTP.................................... 13 1.2.5......................................... 13 1.2.6......................................... 14 1.2.7......................................... 14 1.3. Procesy i SOA................................... 14 1.3.1. Sieci przepªywu pracy........................... 14 1.3.2. Usªugi sieciowe............................... 14 1.3.3. Kraty transakcji.............................. 15 2. Specykacje formalne - 5-10 stron......................... 17 3. System obªugi cash pooli - 5 stron........................ 19 3.1. Cash pool...................................... 19 3.1.1. Zarz dzanie pªynno±ci.......................... 19 3.1.2. Zasada dziaªania.............................. 19 3.1.3. Sytuacja prawna.............................. 21 3.1.4. Korzy±ci................................... 21 3.2. Platforma...................................... 22 3.2.1. Motywacja................................. 22 3.2.2. Wymagania................................. 22 3.2.3. Koncepcja.................................. 23 4. Procesy w systemie - 5 stron............................ 25 4.1. Sposób dziaªania.................................. 25 4.2. Procesy....................................... 25 4.2.1. Proces ko«ca dnia............................. 25 4.2.2. Proces pocz tku dnia........................... 25 4.2.3. Proces dzienny............................... 25 4.3. Kroki procesów................................... 25 3
4.4. Obsªuga sytuacji nieprawidªowych........................ 25 5. Analiza narz dzi - 10 stron............................. 27 5.1. Wyj tki....................................... 28 5.1.1. Idea..................................... 28 5.1.2. J zyki programowania........................... 28 5.1.3. U»yteczno±................................. 29 5.2. Zr by........................................ 31 5.3. Technologie..................................... 31 6. Propozycja rozwi zania - 10-15 stron....................... 33 7. Podsumowanie..................................... 35 Bibliograa......................................... 37 4
Wprowadzenie 5
Rozdziaª 1 Historia - 25-30 stron 1.1. Transakcyjno± Transakcje s bardzo wa»ne w informatyce, dlatego mechanizmy te zostaªy opisane w ogromnej ilo±ci literatury, 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. 1.1.1. Pocz tki 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 zostaª zaadoptowany 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 zostaªy zawarte w pierwszych urz dzeniach obsªugi transakcji takich jak CICS opracowany przez IBM. W bazach danych rzeczywisty stan ±wiata zewn trznego jest modelowany poprzez relacje i krotki, a transformacje s obrazowane jako modykacje 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± (patrz dalej) 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 dwu-fazowe blokowanie, a pó¹niej staªa si podstaw teorii szeregowalno±ci, która ci gle jest baz dzisiejszych rozwi za«zarz dzania wspóªbie»no±ci w bazach danych. Problem odporno±ci na bª dy byª równie» badany w tym okresie i przedostaª si do ±wiata baz danych - [Gray78] opisaª protokoªy DO-UNDO-REDO oraz WAL (write-ahead logging). 1.1.2. ACID Atomowo± Wyobra¹my sobie sytuacj kiedy program wielow tkowy operuje na wspólnej pami ci w wieloprocesorowej maszynie. Niskopoziomowe operacje sprz towe takie jak atomowa wymiana 7
(wymiana zawarto±ci rejestru procesora i jednostki pami ci w jednej niepodzielnej akcji) 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» co 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» jako system) 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 (ewentualnie) podanej warto±ci wej±ciowej, wynikiem akcji (wykonywanej samotnie) 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. Istniej ró»ne klasy bª dów 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. Zakªadamy,»e istnieje trwaªy magazyn danych(ang. stable storage), tzn. gwarantuj cy,»e zapisane w nim dane s odporne na uszkodzenia (wykluczaj c katastrofy czyli rzadkie zdarzenia, które mog skutkowa uszkodzeniem sprz tu i utrat danych). Techniki implementacji takich mechanizmów zostaªy opisane w [Lamp79]. Teraz dochodzimy do poj cia atomowo±ci, wªasno±ci elementarnych akcji, które 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 (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 (stany ko«cowe jej skªadowych) i»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. 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ªych 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. 8
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: trwaªo± - trwaªo± oznacza,»e je±li transakcja si powiedzie (wykona si bezbª dnie i nie zostanie wycofana), 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 zapami taniem(ang. commit). Trwaªo± oznacza,»e kiedy transakcja jest zapami tana, zmiany które wykonaªa s odporne na bª dy (wyª czaj c katastrofy). spójno± - spójno± w bazach danych jest wyra»ana zazwyczaj jako zbiór ogranicze«, np. predykatów okre±lanych na jej stanie. Te ograniczenia odzwierciedlaj wªasno±ci rzeczywistych obiektów reprezentowanych przez baz danych (konta bankowe, inwentarz, zawarto± biblioteki). Poniewa» spójno± jest wymagana 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 atomowo- ±ci, 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 (atomowo± (ang. Atomicy), spójno± (ang. Consistency), izolacja(ang. Isolation), trwaªo± (ang. Durability)) zostaªy przedstawione we wczesnych latach 80-tych (np. [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 ( [GMBL81]), który jako pierwszy wykorzystywaª j zyk zapyta«sql i byª dowodem na to,»e relacyjne bazy danych potra by wydajne ( [SysR-Web]). Powy»sze wªa±ciwo±ci zostaªy uj te 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 1998. Mechanizm dziaªania Transakcje sprzyjaj rozdzieleniu koncepcji, poniewa» pozwalaj programistom skoncentrowa si na logice aplikacji (m. in. dbaniu o spójno± danych biznesowych), podczas kiedy system zarz dzania transakcjami jest odpowiedzialny za zapewnienie pozostaªych wªasno±ci transakcji (atomowo±, izolacja i trwaªo± ). Te trzy cechy s zapewnione dzi ki nast puj cym mechanizmom ( [Gray93]): Izolacja jest osi gni ta przez kontrol wspóªbie»no±ci, podstawowym mechanizmem jest tu blokowanie obiektów. System zarz dzania baz danych zakªada blokady na odpowiednich obiektach kiedy programy na nich operuj. 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 jest stemplowanie obiektów datami systemowymi i zarz dzanie dost pem poprzez kontrol stempli. 9
Atomowo± jest zapewniana przez odzyskiwanie(ang. recovery), która bazuje na mechanizmach logowania. Ka»da modykacja bazy danych jest zapisywana w tabeli loguj cej, która jest przechowywana niezale»nie od samych danych. Odwrócenie mo»e si wykonywa poprzez przywrócenie poprzednich warto±ci ka»dego obiektu znalezionego w logu. Trwaªo± zale»y od atomowo±ci awarii i bazuje na trwaªym magazyn danych. 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, nie byªoby wiadome który stan powinien zosta odtworzony kiedy jedna z operacji wymaga 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 zdeniowane przez programist, b d¹ automatycznie wygenerowane na podstawie deklaracji w ±rodowisku programowania. Kluczowe znaczenie ma fakt,»e powy»sze mechanizmy powalaj caªkowicie ukry przed programist zarówno bª dy jak i przeploty. 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 system zarz dzania transakcjami zapewni zapisanie zmian w bazie danych, pomimo mo»liwych bª dów kolejnych transakcji. Je±li jednak wykonaªa si cze± pracy, ale bª d powstrzymaª program przed zako«czeniem, system wykona odwrócenie niesko«czonej akcji, czyli przywróci dane do stanu sprzed rozpocz cia operacji. 1.2. Rozwój modeli transakcji 3 Advanced transaction models 9.5 Advanced Transaction Models.......................... 9-21 1.2.1. Pªaski model transakcji ACID is good Do you remember when you rst learned to write a program? Perhaps it was in high school. Looking back, remember how simple it was? You didn't worry about the eects of your 10
program failing. You didn't worry about the eects of multiple users and multiple threads of control accessing shared data. You simply wrote your single threaded algorithms on transient data. Maybe you accessed les, but you probably didn't worry too much about it. If you develop challenging distributed enterprise applications and systems, short ACID transactions are your friends. The ACID properties of transactions enable you to write software without considering the complex environment in which the application runs. ACID transactions bring simple high-school programming to the complex real world. With ACID transactions you can concentrate on the application logic and not on failure detection, recovery and synchronizing access to shared data. With ACID transactions, your software need not include logic to recover the state of the application should it fail. Instead you simply dene transaction boundaries in your application and the system ensures atomicity the actions taken within the transaction will happen completely, or not at all. If the application fails midstream, the system will recover to the previous state, as if the transaction never took place. If you have ever written an application without transactions that attempted to detect failures and recover from them, you know that logic can get quite complex. ACID transactions preserve consistency. Assuming there are no bugs in your transaction, the transaction will take the system from one consistent state to another. The good news is that atomicity and isolation make writing a transaction without bugs easier. You focus on getting the application logic correct in the high school programming environment, not in the complex environment. Consistency is especially important in a web application with dynamic servers. When users navigate a web application, they are viewing snapshots of the server state. If the snapshot is computed within a transaction, the state returned to the user is consistent. For many applications this is extremely important. Otherwise the inconsistent view of the data could be confusing to the user. Many developers have the incorrect perception that you don't need transactions if all you are doing is reading a database. If you are doing multiple reads and you want them to be consistent, then you need to do them within a transaction. With ACID transactions, your software need not be a complicated concurrent program in which you explicitly synchronize multiple concurrent activities accessing shared data. The concurrent transactions are isolated from each other. There is concurrency multiple transactions accessing shared data can run concurrently it's just that you do not have to worry about it in your application. The transaction code is written assuming it is the only code accessing the data. The individual actions of a transaction are scheduled to execute according to some notion of correctness. A schedule is serializable if it has the same eect as running the transactions serially, that is just the way you wrote the code. It is up to the system to produce a correct schedule. If you have ever written a complex multi-threaded program, you know it is hard to get it right, test it and debug it. Serializability is a formally dened property that allows you to avoid concurrent programming. Many databases and some application servers weaken serializability with their so-called isolation levels. This requires you to reason about using inconsistent data and this is hard. You have to use application knowledge to argue that a transaction reading an inconsistent, possibly to be rolled-back value, doesn't matter to the correctness of the application. Furthermore, the weaker isolation levels are not the same from one database to another. This makes porting your application very hard. Only until recently have the weaker isolation levels been formally dened. [ALO] Finally, the eects of transactions are durable, that is when a transaction commits the new state is persistently stored. Durable makes for a nice acronym. Take it in Short Doses 11
Unfortunately, ACID transactions do not work eectively over a long period of time. Do not expect things to work if your transactions last more than even a few seconds. Forget putting transaction boundaries around units of work that last minutes, hours, days, months or years. This eliminates dening transactions that do a lot of computation or ones that include user input. Users are nicky they drink coee, go on vacation and die. You cannot expect them to commit their work in a timely manner. This is the so-called long transaction problem. No one has found a solution for it after many years of research. The basic problem is achieving isolation the I in ACID. There are no known concurrency control algorithms that will operate over a long period of time. Concurrency control algorithms for ensuring serializability come in two avors: pessimistic and optimistic. Pessimistic concurrency control algorithms achieve serializable transactions by locking shared resources. In two-phase locking, a transaction obtains its locks in phase 1 and holds on to them until it completes. Competing transactions waiting for the same shared resource block until the rst transaction completes. If the transaction holds the shared resource for a long time, little work is accomplished concurrently because the competing transactions are blocked for a long time. Optimistic concurrency control algorithms let transactions access shared resources and then validate the resulting schedule at commit time. If the schedule violates serializability, the transaction is rolled back. This works when the transactions are short a small amount of work is rolled back. If the transaction is long-lived, the system appears to be humming along but after doing all of that work, it starts rolling back the transactions. When we apply VCRP to evaluate the traditional transactions or at transactions with no internal structures, we get the strict ACID properties that are essential for these relatively simple transactions. The underlying transaction processing (TP) system is responsible for ensuring the ACID properties. A TP system generally consists of a TP Monitor, which is a system program providing a middleware solution to manage 6 transactions and control their access to a Database Management System (DBMS), one or more DBMSs and a set of application programs containing transactions [Lewis et al. 2002]. Atomicity and durability are guaranteed by the mechanism of recovery that is usually implemented by maintaining a log of update operations so that `redo' and `undo' actions can be performed when required. Isolation is guaranteed by the mechanism of concurrency control, which is implemented by using locks during the transaction process. A detailed overview of concurrency control and recovery techniques is available in [Ramamritham and Chrysanthis 1997]. Consistency is guaranteed by the integrity control mechanism usually provided by the TP system, though not complete in a strict sense.1 Flat transactions have proven to be very useful in traditional database applications where the execution time is relatively short, the number of concurrent transactions is relatively small and the database system only resides in one server. However, they lack the exibility to meet the requirements of the applications developed later, for example, multi-database operations that need a certain level of transparency for the interactions with each local database or a workow system that needs to support long-living transactions. 1.2.2. 3.1 The save point concept 12
1.2.3. 3.2 Distributed and nested transactions 9.5.1 Nested Transactions........................... 9-22 Protokoªy Distributed commitment (2PC, 3PC) 9.4 Distributed Transactions............................. 9-15 9.4.1 Atomic Commitment........................... 9-16 9.4.2 Two-phase Commit........................... 9-17 9.4.3 Non-Blocking Commitment Protocols................. 9-18 9.4.4 Optimizing Two-phase Commit..................... 9-20 Business Transaction Protocol free market (protocol) The Tentative Holding Protocol The Two Phase Commit Protocol The Optimistic Two Phase Commit Protocol Paxos Commit 1.2.4. OLTP Mechanizmy wy»ej opisane s u»ywane przez wi kszo± komercyjnych systemów baz danych (niededykowanych) i zostaªy szczególnie zoptymalizowane w kierunku wykonywania operacji biznesowych typowych w lat 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 kilku lat, wraz z rozwojem Internetu, mechanizmy te staj si niewystarczaj ce do nowych wymaga«biznesowych takich jak integracja aplikacji przedsi biorstwa(ang. EAI) oraz integracji przedsi biorstwo-przedsi biorstwo(ang. B2Bi). Nowe potrzeby wyró»niaªa jedna krytyczna cecha: aktywno±ci, które byªy przez nie automatyzowane trwaªy 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. Inn wa»n cech aplikacji OLTP jest to,»e transakcje oddziaªuj w ramach jednej spójnej jednostki kontroli (na pojedynczej bazie danych, pó¹niej rozproszone na kilka instancji, ale zarz dzanych przez jeden system zarz dzania). 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)). LONG RUNNING TRANSACTIONS 1.2.5. 3.3 Chained transactions and sagas 9.5.2 Sagas................................... 9-23 sagas [19] and nested sagas [20, 21] ATM LRUOW ConTract 13
Spheres of Isolation Spheres of Joint Compensation Open Process Management nested transactions [15, 16] multi-level transactions [53] ConTracts WIDE 1.2.6. 1.2.7. 3.4 Conclusion on advanced transaction models 4 ACTA model 4.1 Orginal ACTA framework 4.2 Later developments ACTA [10] 1.3. Procesy i SOA 1.3.1. Sieci przepªywu pracy 4 strony 5 Workow transactions 5.1 The transactional workow concept 5.2 WIDE model 5.3 X-transaction model WIDE (Workow on Intelligent Distributed database Environment) FlowMark Meteor2 Exotica FlowBack FlowMark MQSeries Workow METEOR OpenPM TSME CREW Standardy 1.3.2. Usªugi sieciowe 3 strony 6 Web services transactions 6.1 BTP, WS-Tx and WS-CAF 6.2 Comparing the approaches ECA BPEL4WS Standardy Microsoft XLANG WS-BPEL WS-CDL WSCI 14
WSDL [15] (WSCL [14], WSCI [13], BPML [3], WSFL [10], XLANG [16], BPEL4WS [2]) BPML [2], IBM's WSFL [12], Microsoft's XLANG ([22], [16]) or the more recent BPEL4WS 1.3.3. Kraty transakcji - co z tym??1 strona 7 Grid transactions 7.1 Ongoing work in Grid transactions 15
Rozdziaª 2 Specykacje formalne - 5-10 stron Formal specication of transaction semantics calculus dc t-calculus (biztalk pi? -calculus cjoin calculus StAC (BPBeans) ccsp Sagas calculi dynamic compensation calculus web SOCK (WSDL and BPEL) Event Calculus set consistency 17
Rozdziaª 3 System obªugi cash pooli - 5 stron 3.1. Cash pool 3.1.1. 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 (poza wªasnymi funduszami) ¹ródªem pozyskania ±rodków na nansowanie dziaªalno±ci operacyjnej ka»dego przedsi biorstwa w Polsce 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, które kredytobiorca musi zapªaci za korzystanie z pieni dzy banku. W wi kszych przedsi biorstwach, gdzie struktura organizacyjna bywa cz sto rozbudowana i skomplikowana, cz sto w skªad jednostki wchodz przedsi biorstwa 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. 3.1.2. 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. 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 19
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. Wszelkie zobowi zania powstaªe w tych strukturach s dzielone pomi dzy uczestników struktury proporcjonalnie do ich wkªadu. Rysunek 3.1: Przykªad wykonania kompensacji ±rodków w ko«cu dnia na rachunkach struktury cash pool rzeczywisty Generalnie cash pooling stanowi ofert skierowan i konstruowan specjalnie wedªug potrzeb danego przedsi biorstwa lub grupy kapitaªowej, gdy» jest to sprawa indywidualna. Przewa»nie w ofercie banku istnieje kilka produktów (szablonów usªugi cash pool), które mog zosta odpowiednio skongurowane na potrzeby danego klienta (okre±lenie rachunków w strukturze, harmonogramy wykonania, generowanie raportów). Czasami jednak zdarza si i» w celu obsªu»enia nowego klienta potrzebne jest opracowanie nowego produktu, poniewa» jedynie struktura uwzgl dniaj ca specyk danej jednostki oraz dostosowana do polskich przepisów prawnych, pozwala na usprawnienie zarz dzania ±rodkami rmy. 20
3.1.3. Sytuacja prawna Gªówn przeszkod w powszechnym stosowaniu cash pooli w Polsce s nieuregulowania prawnie zwi zane z tego typu usªugami. Niebezpiecze«stwo interpretacyjne polega na zakwali- kowaniu przez organy podatkowe transferów w ramach cash poolingu jako typowej po»yczki, co skutkuje konieczno±ci zapªacenia 2-proc. podatku od czynno±ci cywilnoprawnych (PCC). Bank odpowiada za dokªadne dopasowanie do specyki danego klienta i musi zaoferowa usªug na zasadach, jakie dana grupa kapitaªowa wypracuje ze swoimi prawnikami oraz organami podatkowymi, aby wyeliminowa ewentualne rozbie»ne interpretacje. Dlatego te» konstrukcja cash pool dla konkretnego klienta jest skomplikowanym tworem prawno-podatkowym, a bank musi wykaza si du» elastyczno±ci. Sposób gromadzenia ±rodków w strukturze, okre- ±lenie udziaªu w kosztach funkcjonowania oraz podziaª zysków musz by ±ci±le dopasowane do konkretnych wymaga«formalnoprawnych. 3.1.4. Korzy±ci Przedsi biorstwa korzystaj ce z usªug cash pool zyskuj na: korzy±ci skali - ª czenie sald kredytowych i debetowych pozwala wynegocjowa znacznie lepsze oprocentowanie ni» w sytuacji, w której uczestnicy negocjuj z bankiem indywidualnie, obni»eniu kosztów prowizji - poniewa» wzajemne nansowanie zachodzi pomi dzy podmiotami powi zanymi to grupa nie ponosi kosztów prowizji bankowych od po»yczek udzielonych poszczególnym uczestnikom, bardziej efektywnym zarz dzaniu pªynno±ci, zachowaniu autonomii nansowej podmiotów podporz dkowanych. Powy»sze korzy±ci dostrzegli duzi klienci, wi c bank, chc c pozosta dla klienta atrakcyjnym partnerem, nie mo»e sobie pozwoli na brak usªug cash pool w swojej ofercie. Aby cash pool byª w peªni efektywny, wszystkie rachunki operacyjne grupy kapitaªowej powinny by prowadzone w jednym banku. Jest to dla banku bardzo dobra sytuacja, gdy» dzi ki temu ma mo»liwo± przej obsªug bankow caªej grupy. 21
3.2. Platforma 3.2.1. Motywacja Cash pool mogªby by realizowany we wªasnym zakresie przez grup kapitaªow. Taki mechanizm ma istotne wady. Mo»e absorbowa znaczn ilo± pracowników, którzy nawet przy najlepszych zamiarach nie b d wykonywali usªugi efektywnie ze wzgl du na opó¹nienia w operacjach mi dzy bankami oraz fakt,»e przed zamkni ciem dnia klient mo»e nie zna swojego salda zamkni cia. Lepszym rozwi zaniem dla grup kapitaªowych jest ±wiadczenie przez bank usªug zarz - dzania pªynno±ci. Mo»e to by wykonane operuj c na saldach zamkni cia ka»dego dnia. Aby caªy proces zostaª zautomatyzowany, a raporty dziaªania struktury na bie» co dost pne dla klienta, banki oferuj ce swoim klientom rozwi zania pªynno±ciowe zaopatruj si w odpowiednie aplikacje. Istniej dwie mo»liwo±ci: obsªuga w ramach systemu centralnego lub w odr bnym dedykowanym do tego celu systemie. Wykorzystanie systemu centralnego ma wiele zalet. Przede wszystkim: taki system w ka»dym banku funkcjonuje i je±li ma wbudowan obsªug usªug typu cash pool to wdra»anie usªug mo»e by szybkie. Rozwi zanie to nie jest jednak perspektywiczne, gdy» zwykle udost pnia jedynie najprostsze warianty usªug lub nieodpowiednie do polskich realiów prawnych. Dostosowanie lub tworzenie nowych usªug dedykowanych w systemie centralnym jest dªugotrwaªe i kosztowne. Dodatkowo takie zmiany mocno ingeruj w podstawowe funkcje systemu, wi c zmiany b d za sob poci ga testy caªego systemu centralnego. Jest to proces dªugotrwaªy i w dªu»szej perspektywie zbyt m cz cy i ograniczaj cy. System zewn trzny natomiast cechuje si wysok elastyczno±ci w dostosowywaniu si do wymaga«indywidualnych klientów. Dostosowanie usªugi b dzie o wiele ªatwiejsze, czyli ta«sze dla banku, a czas wykonania i udost pnienia klientowi krótszy. System b dzie musiaª integrowa si z systemem centralnym, ale wykorzystuj c standardowe interfejsy, takie jak ksi gowanie transakcji czy pobieranie salda, uda si to z ªatwo±ci. Dodatkowo system dedykowany do obsªugi cash pool b dzie rozumiaª logik usªug. Operatorzy b d mieli ªatwiejszy dost p do analizowania wykonania poszczególnych struktur poprzez prezentacj wyników dzia- ªania, takich jak naliczone odsetki, salda przed i po wykonaniu usªugi oraz rozliczenia mi dzy uczestnikami. 3.2.2. Wymagania System obsªuguj cy usªugi cash pool musi zapewnia szeroki wachlarz produktów. Sam cash pool wydaje si by usªug, któr ªatwo jest zautomatyzowa. Niestety z powodu indywidualnego dopasowania do klienta przewidzenie wszystkich wariantów jest niemo»liwe. Z tego powodu znacznie wa»niejsza od ilo±ci gotowych usªug jest mo»liwo± uszycia struktury na miar dla konkretnego klienta. Dlatego system powinien charakteryzowa si du» elastyczno- ±ci w zakresie konstruowania najbardziej skomplikowanych usªug, dzi ki czemu bank ªatwo i szybko b dzie mógª reagowa na zmieniaj ce si trendy rynkowe i skutecznie rywalizowa z konkurencj. Kolejnym wa»nym wymaganiem jest ªatwo± obsªugi. Poniewa» jest to system dedykowany, powinien dawa du»o lepsze mo»liwo±ci prezentowania wyników dziaªania konkretnych cash pooli. Nie mniej wa»ne jest te» zautomatyzowanie procesów uruchamiania usªug. System nie powinien wymaga ingerencji operatora kiedy usªug nale»y uruchomi kilka razy dziennie. Sama automatyzacja procesów nie wystarczy. W sytuacjach kiedy zªo»one operacje mog wykonywa si pod nieobecno± operatorów wszelkie automatyczne procesy powinny zawiera wyranowane mechanizmy obsªugi sytuacji niepo» danych. 22
Kompleksowy system udost pniaj cy zªo»on funkcjonalno± powinien posiada modularn budow, aby mógª by z ªatwo±ci wdro»ony w dowolnym banku. Moduªy dodatkowe powinny by w peªni odseparowane z mo»liwo±ci niezale»nego doª czania do systemu. Pozwala to na oszcz dno±ci banku w przypadku ch ci oferowania prostszych usªug, b d¹ zast - pienie moduªów przez istniej ce wewn trzne systemy banku, np. system naliczania opªat. Integracja z systemem centralnym pomimo,»e wykorzystywa b dzie standardowe interfejsy banku mo»e wymaga szczególnej uwagi podczas wdro»enia. Aby wdro»enie w dowolnym banku odbywaªo si bez wi kszych komplikacji, nale»y przygotowa si na konieczno± przygotowania kilku mechanizmów wykonywania tej samej operacji, np. ksi gowanie transakcji synchroniczne/asynchroniczne, generowanie raportów do pliku/kolejki komunikatów. Z tego powodu automatyczne procesy biznesowe powinny by kongurowalne zgodnie z wymaganiami konkretnego banku. 3.2.3. Koncepcja podzial na moduly, konguracja... diagramy... 23
Rozdziaª 4 Procesy w systemie - 5 stron 4.1. Sposób dziaªania przetwarzanie uslug, dlaczego procesy, co sie wtedy dzieje... 4.2. Procesy w kazdym z nich: kiedy uruchamiany, jak to jest z czasem, jakie operacje sa w nim wykonywane (z jakich krokow moze sie skladac) diagramy... 4.2.1. Proces ko«ca dnia 4.2.2. Proces pocz tku dnia 4.2.3. Proces dzienny 4.3. Kroki procesów poszczegolne kroki z ktorych mozna budowac procesy + ich warianty 4.4. Obsªuga sytuacji nieprawidªowych jakie sytuacje nieprawidªowe przewidujemy w systemie i jak chcemy na nie reagowa w ró¹nych krokach procesu 25
Rozdziaª 5 Analiza narz dzi - 10 stron 27
5.1. 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. 5.1.1. Idea Obsªuga wyj tków (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. 5.1.2. 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. 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 specjalnego znacznika (zazwyczaj try albo inna konstrukcja rozpoczynaj ca blok jak begin) a ko«czy przy pierwszej klauzuli 28
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 5.1: Przykªad obsªugi wyj tku dzielenia przez zero. 5.1.3. 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. Poni»ej opisz plusy i minusy korzystania z tego mechanizmu. 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 u»ywana przez lenistwo programistów w radzeniu sobie z nimi. 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
Korzy±ci 1. Niezawodno± - W niektórych aplikacjach przerwanie poprzez bª d jest niedopuszczalne. Niespójno± danych albo wycieki pami ci mog by akceptowalny 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ª nadu»ywana, wi c aktualnie nie poleca si jej u»ywania, z nowoczesne 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 czasie 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
5.2. Zr by middleware platforms BizTalk 9.6 Transactional Middleware............................ 9-24 9.6.1 Transaction Management in JEE.................... 9-25 9.6.2 Web Services Transactions........................ 9-26 9.6.3 Advances in Transactional Middleware................. 9-29 9.7 GoTM, a Framework for Transaction Services................. 9-29 9.7.1 Architecture of GoTM.......................... 9-30 9.7.2 Implementation of GoTM........................ 9-32 9.7.3 Using GoTM............................... 9-34 5.3. Technologie CORBA Activity Service Framework EJB Bourgogne Transactions X2TS PJama 31
Rozdziaª 6 Propozycja rozwi zania - 10-15 stron 33
Rozdziaª 7 Podsumowanie 35
Bibliograa W zestawieniu podane s publikacje w caªo±ci lub cze±ci wykorzystane przez autora w trakcie przygotowania pracy, jak równie» materiaªy, przydatne w celu szerszego poznania tematu. [Bern87] [Eswa76] [Except] [GMBL81] [Gray78] [Gray81] [Gray93] [Haer83] [Lamp79] [SysR-Web] [Weik02] P. A. Bernstein, V. Hadzilacos, N. Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, 1987. K. P. Eswaran, J. N. Gray, R. A. Lorie, I. L. Traiger, The notions of consistency and predicate locks in a database system, Communications of the ACM, 1976;19(11):624633. Exception Handling. http://neil.fraser.name/writing/exception/ J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price, F. Putzolu, I. Traiger, The recovery manager of the System-R database manager, ACM Computing Surveys, 1981;13(2):223242. J. Gray, Notes on data base operating systems, Operating Systems: An Advanced Course, London, UK. Springer-Verlag, 1978:393481. J. Gray, The transaction concepts: Virtues and limitations, Proceedings of the 31st International Conference on Very Large Data Bases (VLDB'05), France, 1981:144-154. J. Gray, A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1993. T. Haerder, A. Reuter, Principles of Transaction-Oriented Database Recovery, ACM Computing Surveys, 1983;15(4):287317. B. W. Lampson, H. E. Sturgis, Crash recovery in a distributed data storage system, Technical report, Xerox PARC (unpublished), 1979. Cz - ±ciowo odtworzone w Distributed Systems Architecture and Implementation, red. Lampson, Paul, Siegert, Lecture Notes in Computer Science, Springer, 1981;105:246265,357370. System R website. http://www.mcjones.org/system_r/ G. Weikum, G. Vossen, Transactional Information Systems, Morgan Kaufmann, 2002. 37