Обробка транзакцій

Содержание Введение… 3 1. Основи обробки транзакцій… 4 2. Принципи і моделі обробки транзакцій… 5.

2.1. Пласкі транзакції… 6.

2.2. Контрольні точки… 8.

2.3. Многозвенные транзакції… 10.

2.4. Вкладені транзакцію… 11.

3. Encina і DCE… 14.

4. X/Open DTP… 17.

5. Класифікація систем обробки транзакцій… 19.

6. Мови транзакцій… 20 7. Монітори обробки транзакцій третього покоління… 21 Заключение…24 Литература.

У цьому курсової роботі обговорюються тенденції і обробки транзакцій на застосування до системам інформаційного управління у цілому. Розглядаються, зокрема, такі вопросы:

. принципи обробки транзакцій на інформаційних системах;

. останні досягнення у світі комерційних систем обробки транзакций;

. мови обробки транзакций;

. стандарты;

. риси систем обробки транзакцій наступного поколения.

1. Основи обробки транзакций.

Можна розглядати обробку транзакцій на узагальненому вигляді, включаючи безліч парадигм — від пакетної та простий терминально-интерактивной обробки (насправді концептуальними джерелами комп’ютерного опрацювання транзакцій вважатимуться шумерські глиняні таблички з записами торгових операцій, зробленими за багато тисячоліття до зародження ідеї обчислювальної машини). Конкретніше, дисципліна транзакцій включає в собі різноманітні функції на підтримку комп’ютерних додатків, заснованих на виключно комунікаціях. У узагальненому сенсі системи обробки транзакцій можуть охоплювати усе, що можуть бути у комп’ютерній системі: бази даних, мережі, операційні системи та т.д.

У сфері обробки транзакцій має місце наступна класифікація (рис. 1).

[pic].

Малюнок 1. Покоління систем обробки транзакцій. — Перше покоління. Єдині монолітні системи, які з користувачем у вигляді найпростіших терминалов.

— Друге покоління. Підтримка продуктів багатьох постачальників, інтелектуальні клієнтські системи, підтримка безлічі систем баз даних, зазвичай, з допомогою протоколів двухфазовой фіксації (в другому поколінні відбиває нинішній стан справ у цій галузі). — Третє покоління. Який Зароджується покоління систем, більш адекватно, ніж може бути сьогодні, що відбиває потреби бизнеса.

Хоча поняття «обробка транзакцій «застосовно практично до будь-якої комп’ютерної середовищі, особливо у бізнесі, проте традиційно використання моніторів обробки транзакцій обмежувалося окружениями великомасштабних центрів обробки даних, функціонуючих з урахуванням мэйнфреймов, в прикладних областях, як резервування авіаквитків чи міжнародні банківські операції. Останніми роками, почасти з допомогою те, що корпоративні інформаційні системи дедалі більше набувають риси распределенности і неоднорідності, монітори обробки транзакцій стали застосовуватися та у багатьох інших вертикальних додатках (охорону здоров’я, страхування, торгівля). За оцінками Gartner Group, до 1995 р. в 50% знову створюваних додатках з урахуванням реляционных СУБД придадуться кошти обробки транзакций.

Звернімося тепер до фундаментальним принципам і основним моделям транзакцій, які визначають шляху застосування транзакцій на інформаційних системах.

2. Принципи і моделі обробки транзакций.

До всіх типам транзакцій пред’являється набір вимог, відомий під назвою ACID (atomocity, consistency, isolation, durability). Сенс цих вимог ось у чому. — Атомарность. Транзакція є певний набір дій. Система забезпечує виконання за принципом «усі поголовно чи нічого «- або виконуються всі дії, т. е. транзакція фіксується, або виконується жодна, т. е. транзакція переривається. — Узгодженість. Передбачається, у результаті транзакції система переходить вже з абстрактного коректного стану до іншого. Поняття транзакції дозволяє програмісту декларувати умови таких узгоджених станів даних, а системі - підтверджувати узгодженість, виробляючи достойні додатку перевірки. — Ізольованість. Оскільки транзакція змінює розділяються дані, всі вони можуть тимчасово перебувати у несогласованном стані. Дані, які перебувають в несогласованном стані, нічого не винні бути видно іншим транзакциям, поки зміни буде завершено (т. е. доки всі модифікації ні формально зафіксовано). Система забезпечує кожної транзакції ілюзію те, що та виконується ізольовано, коли б інші транзакції або завершилися до початку спілкування, або почнуть виконуватися після завершення. — Довговічність. Якщо транзакція зафіксована, що його результати повинні бути довговічними. Нові стану на всі об'єкти збережуться навіть тоді апаратних чи системних сбоев.

Існують численні моделі транзакцій, підтримують ці принципи. Вони варіюються від найпростіших, як-от «плоскі «транзакції, до витончених, як-от вкладені чи многозвенные. Розглянемо ці моделі докладніше, оскільки складні моделі у значною мірою визначають особливості обробки транзакцій на комерційних інформаційних системах будущего.

2.1. Пласкі транзакции.

Моделі пласких транзакцій відповідає один управляючий шар, якій підпорядковано довільне число елементарних дій. У середовищі сучасних інформаційних системах — це, зазвичай, єдина підтримувана на прикладному рівні модель транзакцій, хоча внутрішні компоненти системи (наприклад, SQL) можуть включати витонченіші кошти обробки транзакцій; але вони не доступні лише на рівні прикладного программирования.

Пласкі транзакції - це основні будівельні блоки для реалізації принципу атомарности; інакше кажучи, виділення деякою послідовності дій як пласкою транзакції забезпечує принцип «усі поголовно чи нічого » .

Багато прикладних оточеннях, особливо з централізованими опрацюванням і управлінням ресурсами (наприклад, базами даних, і файлами), механізм пласких транзакцій уже багато років надавав цілком задовільні можливості до створення, так виконання додатків; прості перетворення станів системи цілком вкладалися у рамки атомарних одиниць работы.

Принаймні того як дані і обчислення стають дедалі більше розподіленими, атомарность пласких транзакцій стає значним незручністю. Розглянемо приклад на рис. 2. Відповідно до правил обробки пласких транзакцій, або повинні успішно завершитися все компоненти глобальної транзакції, або має завершитися жодна їх. Наприклад, якщо невдачею завершилося тільки зміну однієї віддаленій бази даних під управлінням деякого менеджера ресурсів, те й й інші компоненти мають повернути до стану, попереднє початку транзакції. Зважаючи на кількість інформації, оброблюваної у великій і навіть середньої організації з безліччю серверів LAN на ПК і, можливо, з мобільними базами даних, можна припустити, що ймовірність відмови хоча самого вузла дуже висока. Якщо застосовується модель пласких транзакцій, доведеться наново виконувати все складові транзакції, що підвищує вимоги до обчислювальним ресурсів і віднімає значну частину пропускну здатність системы.

[pic].

Малюнок 2. Виконання пласкою транзакції серед великої организации.

Вочевидь, що у століття сильно розподілених обчислень необхідно якимось чином проводити декомпозицію пласких транзакцій. Модифікація моделі пласких транзакцій, яка зберігає властивість атомарности, але яка б знизила потреба у повторному виконанні дій (т. е. в «переробках »), включає поняття контрольних точок, яку ми обговоримо наступного разделе.

2.2. Контрольні точки.

Контрольні точки встановлюються в прикладної програмі у тому, щоб відзначити моменти, починаючи із яких продовжити обчислення в разі проблем. У ідеалі контрольні точки повинні відповідати частково узгодженим станам (наприклад, після побудови допоміжної таблиці у програмі, які потім буде використовуватися для обчислень з участю ще будь-якої таблицы).

Після досягнення черговий контрольної точки в транзакції створюється нове атомарну дію, яке запускається виконання. Тільки останнє атомарну дію всієї послідовності може виконати фіксацію (COMMIT WORK) транзакції; оператор COMMIT WORK передається всім попереднім атомарным діям, доки всі вона буде зафіксовано. У на відміну від моделі многозвенных транзакцій, які ми розглянемо в наступному розділі, контрольна точка не призводить до необоротною фіксації, виконаною доти работы.

Переривання (ROLL BACK), чи відкоти, транзакції можуть ініціюватися із будь-якої атомарної дії, Не тільки з останнього; хоча у будь-який поставлене час переривання може ініціювати лише діяння, запущена останнім. (Це означає, що й для якогось атомарної дії було досягнуто контрольна точка, то тут для цього дії не можливо, у подальшому ухвалено рішення про відкоті.) Відкіт то, можливо зроблено до кожній із попередніх контрольних точок, тому менеджер обробки транзакцій повинен сприймати параметр, який би, аж як саме контрольної точки треба провести відкіт (в ідеалі логіка докладання має передбачати визначення контрольної точки, до якої у разі невдачі слід відкотити выполнение).

Проводилися дослідження з вивченню застосовності так званих стійких (persistent) контрольних точок, які фіксуються в дискової або інший довгострокової пам’яті, щоб результати виконання були доступні після системних крахов. Проте Грей і Реутер відзначають, що «не видно поки що ніякої рішення, що можна було б прийняти беззастережно ». Це навряд чи можна вважати великий проблемою, оскільки дві нові моделі транзакцій — вкладені і многозвенные транзакції - надають схожі можливості тим більше, що формальні визначення цих парадигм набагато краще пророблені й загальноприйняті. Розглянемо спочатку многозвенные транзакции.

2.3. Многозвенные транзакции.

Модель многозвенных транзакцій (рис. 3) концептуально подібна моделі контрольних точок, але він передбачає фіксацію частини роботи, зробленою до певного моменту; можливість відкоту зафіксованих дій исключается.

[pic].

Малюнок 3. Концептуальне уявлення многозвенных транзакций.

Додаток тим щонайменше залишається може транзакції; т. е. при цьому відбувається ініціації черговий транзакції, її завершення, ініціації наступній і його завершення тощо. буд. У межах многозвенной транзакції збережено всі необхідні елементи контексту виконання (курсоры баз даних, відкриті файли тощо. буд.), хоча ресурси, які є непотрібними, можна освобождать.

Модель многозвенных транзакцій включає оператор CHAIN WORK — неподільну комбінацію операторів COMMIT WORK і BEGIN WORK, — яка неравноценна послідовному виконання операторів COMMIT WORK і BEGIN WORK окремо. За виконання цих операторів окремо контекст пропадає; деяка інша транзакція може «вклинитися «й змінити значення базі даних, які потрібні до виконання наступного «ланки «многозвенной транзакції, як цієї ланки почне виконуватися. Таким чином, многозвенные транзакції концептуально еквівалентні транзакциям з контрольними точками з тією відмінністю, що відкіт може проводитися тільки до останньої зафіксованої точки, а чи не до будь-який попередньої контрольної точки.

Обидві моделі транзакцій — многозвенные і з контрольними точками — дозволяють описувати послідовності дій; відмінності стосуються лише можливостей відкоту і стійкості виконаних до заданої точки дій. Остання модель, що її обговоримо, — це модель, що дозволяє описувати не послідовності, а ієрархії субтранзакций.

2.4. Вкладені транзакции.

Модель вкладених транзакцій включає поняття головний транзакції, який управляє виконанням всієї ієрархії. У межах ієрархії можуть може бути транзакції різних рівнів вкладеності (рис. 4). Кінцеві вузли ієрархії є плоскі транзакції. Окремі галузі ієрархії може мати різну довжину, т. е. кінцеві транзакції можуть перебувати на різному «відстані «головного транзакції (деревокореня транзакций).

[pic].

Малюнок 4. Структура вкладених транзакций.

Правила і моделі вкладених транзакцій були вперше розроблено Эллиотом Моссом в 1981 року. У моделі Мосса реальні дії могли проводитися тільки кінцевими субтранзакциями, але Грей і Реутер відзначають, що цього правила обмежує функції вкладення транзакцій що його скасування дає додаткових можливостей розпаралелювання дій над поділюваними об'єктами під час введення абстракції багаторівневих объектов.

Мосс сформулював три правила керувати вкладеними транзакциями:

— Правило фіксації. Виконання оператора COMMIT WORK у певній субтранзакции робить його результати видимими лише батьківської транзакції. Фактична фіксація субтранзакции відбувається після фіксації всіх його предків до головний транзакции.

— Правило переривання (відкоту). Якщо субтранзакция деякого рівня, включаючи головну, відкочується, той самий має зроблено для всіх його нащадків, незалежно статусу фіксації кожної на локальному уровне.

— Правило видимості. Усі дії, виконані рамках субтранзакции, у її фіксації стають видимими батьківської транзакції. Усі об'єкти, захоплені деякою транзакцией, доступні її нащадкам. Сусідні транзакції (які стосуються одному рівню та мають загального батька) «невеликі «одна одній ані в, ні з іншому сенсі, що дозволяє виконувати їх параллельно.

З властивостей ACID для субтранзакций виконуються властивості атомарности, узгодженості і ізольованості. Але оскільки COMMIT WORK для субтранзакции насправді значить її фіксації до фіксації всієї транзакції, то властивість довговічності не виконується, тому субтранзакции не еквівалентні пласким транзакциям.

Як і інші моделі, вкладені транзакції мають варіації, у цьому числі модель багаторівневих (multilevel) транзакцій, де субтранзакция ST1 «попередньо фіксує «результати. У цьому нею передбачена компенсирующая субтранзакция, яка може скасувати виконані ST1 дії, якщо з’являється переривання всієї транзакції загалом. Компенсуючі транзакції дозволяють скасовувати результати майже реальному часу; у тому відсутність доводиться застосовувати сценарії відновлення з аналізом часу вироблених змін, навіщо використовуються дорогі оперативні ресурси, щоб забезпечити повернення бази даних в узгоджене стан (наприклад, із застосуванням журналів чи шляхом «зіставлення фрагментів «головоломки-мозаики, щоб визначити, яким має бути узгоджене стан бази данных).

Хоча можна уявити докладання і системи, у яких многозвенные і вкладені транзакції було б корисні, однак лише на початку 90-х у комерційних банках додатках змінюють пласким транзакциям почали приходити інші. Цікаво, втім, відзначити, що з вивченні транзакцій SQL можна знайти деякі ознаки «псевдовложенности », по крайньої мері у засобах обробки операторів (це у час недоступно розробникам додатків; проте прийнятий у час стандарт SQL3 містить контрольні крапки й, мабуть, до нього ввійдуть оператори управління многозвенными транзакциями).

На рис. 5 показано виконання транзакції SQL. Кожен оператор всередині транзакції, що дає, наприклад, послідовність операторів UPDATE і DELETE, може завершитися успішно чи неуспішно. Навіть якщо одне чи кілька операторів завершуються невдачею, транзакція загалом може тривати досить, якщо в логіці тих випадків року передбачено переривання з відкотом в початкова стан. Усі успішно які завершилися до переривання оператори (які у цій моделі можна становити як субтранзакции) скасують, якщо з’являється відкіт всієї транзакции.

[pic].

Малюнок 5. SQL як псевдовложенных транзакций.

Розробникам додатків доводилося якось компенсувати недоступність наявних у SQL властивостей псевдовложенности, застосовуючи різні хитрощі для побудови архітектур транзакцій, які відповідають їх потребам, ніж найпростіші плоскі транзакції. Коли над ринком утвердиться стандарт SQL3, й розпочнуть з’являтися сумісні з нею продукти, розробники додатків з урахуванням SQL СУБД зможуть безпосередньо користуватися перевагами нових моделей транзакций.

3. Encina і DCE.

Монітор обробки транзакцій Encina корпорації Transarc можна розглядати, як комерційний продукт другого покоління, проте він більше розвинений, який відбиває новітні досягнення у цій галузі. Encina включає модель вкладених транзакцій і розширює можливості середовища DCE (Distributed Computing Environment), запропонованої організацією OSF (Open Software Foundation).

Прообразом Encina був прототип системи обробки транзакцій Camelot, розроблений університеті Карнегі-Меллон в Піттсбурзі. Технологія, що у основі Camelot, і застосовуваний у в цій системі мову програмування Avalon описані у роботі Camelot and Avalon: A Distributed Transaction Processing Facility. Camelot вважається «першої реалізацією вкладених транзакцій на системі обробки транзакцій «(на відміну псевдовложенности, що її обговорювали у минулому розділі, чи то з внутрісистемної вкладеності, недоступною для розробників приложений).

Архітектура, відображено на рис. 6, відповідає ступеня распределенности, властивій розроблюваних чи проектованих в час інформаційних систем. Використання серверів додатків тут відповідає філософії виділення процедур обробки даних, в на відміну від філософії виділення самих даних. Хоча користувачі, мають достатні повноваження, можуть безпосередньо здійснювати доступом до віддаленим даним, але в разі мета у тому, щоб надалі повністю передати управління даними серверам приложений.

[pic] Малюнок 6. Відкрита прикладна середовище розподіленої обробки транзакций.

На рис. 7 зображений типовий багаторівневий підхід до розподіленої обробці транзакцій, застосовуваний, зокрема, в DCE. Монітор Encina використовує надані DCE абстрактні рівні управління ресурсами і комунікаційних менеджерів і саме забезпечує пряме підключення до ресурсів і комунікаційним менеджерам, не підлеглим DCE. Модульність і багаторівневість — риси, характерні сучасних відкритих систем і корпоративних обчислювальних архітектур, — відображаються і у фортепіанній обробці транзакцій. Можна з упевненістю передбачити, що концепції відкритих систем надалі ще активніше застосовуватися у сфері обробки транзакций.

[pic].

Малюнок 7. Багаторівнева архітектура обробки транзакцій на Encina.

Одне із завдань, розв’язуваних монітором Encina, — це підтримка властивостей ACID серед баз даних клієнт-сервер за умови, що клієнти і сервери незалежно зберігають записи про стан транзакций.

У Encina код, який би дотримання властивостей ACID, полягає у менеджерах ресурсів (див. рис. 7); докладання та інші програми верхнього рівня видають запити на фіксацію чи переривання транзакцій, які менеджери транзакцій реалізують на відповідних ресурсах нижнього уровня.

Encina включає мову розробки додатків Transactional З, у якому набір макросів і бібліотек визначення транзакцій і управління ними. Ключове слово TRANSACTION служить визначення транзакцій верхнього рівня або вкладених. Функції, поставлені з допомогою ключових слів ONABORT і ONCOMMIT, описують дії, що їх при відкоті чи, відповідно, фіксації транзакції рівня. Програма може викликати ENCINA_ABORT_ALL, щоб викликати переривання всієї транзакции.

Цікаво було б поспостерігати, як піде розвиток як конкретного продукту Encina, але й області «відкритої обробки транзакцій «загалом. Тенденції посилення распределенности і неоднорідності, що спрямовують розвиток технологій баз даних, і інформаційного управління, вимагають певної міри відкритості всіх компонентів інформаційних систем (зокрема сервісів операційними системами, безпеки, баз даних, моніторів транзакцій). Хоча старі «закриті «продукти і апаратні платформи, підтримувані ними, проіснують ще тривалий час, але тенденції, які ілюструє рис. 8, неминуче будуть надавати дедалі більше значний вплив в розвитку систем обробки транзакций.

[pic] Малюнок 8. Чинники, що впливають розвиток комерційних моніторів обробки транзакций.

4. X/Open DTP.

Ще одна визначальний чинник розвитку комерційних систем обробки транзакцій — це стандартизація. Міжнародний комітет із стандартам (ISO) виробив що з двох частин протокол на підтримку медоперабельности систем обробки транзакцій. Дві складові цього стандарта:

. OSI-TP для сервісів обробки транзакцій, 1992 г.;

. OSI-CCR для фіксації, управління і відновлення, 1990 г.

Стандарти OSI визначають формати і протоколи, але з прикладні програмні інтерфейси для стандартного протоколу двухфазовой обробки транзакцій (2PC), спроектованого як надбудова над стеком комунікаційних протоколів OSI.

Стандарт АПІ розроблений комітетом X/Open й отримав назву X/Open Distributed Transaction Processing (DTP) АПІ. X/Open DTP дозволяє менеджерам транзакцій використовувати комбінацію закритих і OSI-TP-протоколов для внутрішніх та межоперабельных оточень відповідно. X/Open DTP — стандарт, що у стадії початкового розвитку та має певні протиріччя. Зокрема, трохи зле узгоджуються дві цієї мети: (1) визначення середовища монітора TP як стандартизованого оточення і (2) підтримка віддалених викликів процедур транзакцій (TRPC — Transactional Remote Procedure Calls) поруч із «рівноправними «(peer-to-peer) моделями комунікацій (по крайнього заходу нині модель X/Open DTP містить обидва подхода).

X/Open DTP підтримує як плоскі транзакції, але й многозвенные і вкладені (у вищій з цих моделей при перериванні однієї гілка відбувається переривання всієї транзакції в целом).

У стандартизованої розподіленої середовищі TP для описи взаємодій між компонентами застосовується комбінація стандартних протоколів. Деякі їх, наприклад ROSE (Remote Operations Service), ставляться до спільного стеку протоколів OSI; інші є специфічними для оточення X/Open DTP чи OSI-TP. На рис. 9 показані інтерфейси компонентів в стандартизованої розподіленої середовищі TP й формує відповідні протоколи і API.

[pic].

Малюнок 9. Стандартизированная середовище обробки транзакций.

5. Класифікація систем обробки транзакций.

З появою безлічі стандартизованих систем обробки транзакцій нової генерації корисним представляється проведення їх класифікації з погляду спектра надання функцій. Таку класифікацію, що включає п’ять вимірів, запропонували Абрахам Лефф і Калтон Пу з Колумбійського университета:

M — безліч машин;

P — безліч процессов;

H — ступінь неоднорідності машин та програмного обеспечения;

D — безліч логічних данных;

P.S — безліч узлов.

Ця класифікація характеризує будь-яку систему обробки транзакцій, від найпростіших (P1, M1, H1, D1, S1) до складних многоузловых неоднорідних оточень із підтримкою різнотипних наборів даних (Pn, Mn, Hn, Dn, Sn). У статті, написаної 1991 р., ці автори представили тривимірну класифікацію, що вони застосували з метою оцінки різних дослідницьких і численних комерційних систем.

6. Мови транзакций.

У разд. 4 було розглянуто Encina — монітор транзакцій корпорації Transarc — що включає безліч бібліотек та макросів, складових середу розробки Transactional З. Альтернативний спосіб завдання директив обробки транзакцій полягає у застосуванні спеціального мови. Як прикладу розглянемо мову InterBase Parallel Language (IPL), входить у склад неоднорідною розподіленої cреды баз даних InterBase, що її обговорювали в гол. 6. IPL розроблений з урахуванням підтримки високого рівня паралелізму і взаємодії між субтранзакциями, які належать загальної глобальної транзакції. IPL призначався на підтримку транзакцій різних типів (т. е. змішаних транзакцій), і навіть як системно-независимый декларативний мову, який би прозорість управління транзакциями.

Програма на IPL є блок, обрамлений ключовими словами program — endprogram, і включає декларації записів та описи субтранзакций. Оскільки IPL постійно розвивається й у зараз у стадії досліджень перебуває графічний інтерфейс, і навіть объектноорієнтована версія цієї мови, то «за повнішої інформацією ми відсилаємо читача до матеріалів проекту InterBase, що ведеться в Університеті Пурдью.

Альтернативний підхід до специфікації транзакцій — використання мови, орієнтованого не так на глобальну схему чи специфічну для будь-якого продукту реалізацію, але в нейтральну семантичну модель даних. У зв’язку з зростаючій роллю моделювання даних застосування архітектур транзакцій безпосередньо до семантичної моделі також набуває важливе значение.

Значення цих коштів визначається почасти тим, що вони сприяють інтеграції концептуального моделювання процесів і передачею даних. Класичні процедури інтеграції 70-х років орієнтувалися, наприклад, на відображення діаграм потоків даних (DFD — Data Flow Diagram), на сутності та атрибути діаграм сущность-связь (ERD — Entity-Relation Diagram). Объектноорієнтоване моделювання забезпечує визначення об'єктів разом із властивими їм операціями, але ні перший ні другий вид моделювання зовсім позбавлений коштів на описи семантики транзакцій. Вироблення мов описи транзакцій стосовно деякою моделі даних із наступним перенесенням мовних засобів у середу, що забезпечує графічне уявлення вкладених, многозвенных та інших розвинутих моделей транзакцій, дасть в майбутньому значне збільшення продуктивності й надійності проектування систем обробки транзакций.

7. Монітори обробки транзакцій третього поколения.

Перш ніж завершити цей розділ, звернемося вкотре до моніторам обробки транзакцій третього покоління, згаданих в разд. 2. До найважливішим характеристикам нової генерації коштів обробки транзакцій ставляться следующие.

— Моделювання бізнес-процесів і управління ними. У минулому розділі ми розглянули основних напрямів розвитку мов описи транзакцій. Філософія обробки транзакцій на час, навіть оточень, сумісних з OSI-TP і X/Open DTP, орієнтована на убудовування специфікацій транзакцій й логіки управління у докладання. Вкрай бажані було б незалежні декларативні кошти на описи семантики транзакцій на термінах бизнес-операций, точніше, їх моделювання разом із логікою бизнес-операций, на підтримку що вони предназначены.

— Інтеграція з дисципліною потоків робіт. Незалежні кошти моделювання і специфікації транзакцій, відзначені у минулому пункті, необхідно з'єднати все із що формується нині дисципліною потоків робіт. Для описи потоків інформації, якої обмінюються між собою користувачі, процеси, докладання, може застосовуватися певний высокоуровневый мову чи графічна система. У цьому семантику транзакцій можна було б описувати безпосередньо над специфікаціями потоків робіт, аналогічно як його можна було б ставити щодо деякою семантичної моделі даних. Маючи середу розробки, з інструментами генерації систем, можна було б генерувати оточення управління транзакціями (сумісні, цілком імовірно, з X/Open DTP) разом із процедурами й уявленнями даних, необхідні реалізації комбінованої моделі «потоки робіт — транзакції - дані «.

— Тривалі транзакції. Раніше ми відзначали необхідність довгострокових транзакцій для объектно-ориентированных баз даних. Хоча як така ця потреба вже усвідомлено, але висловлення властивостей і реалізації механізмів таких транзакцій необхідні нові абстракції. Монітори обробки транзакцій третього покоління повинні підтримувати тривалі транзакції поруч із традиційними короткочасними транзакциями.

— Розширюваність. Монітори TP третього покоління повинні мати властивістю динамічної расширяемости новими моделями транзакцій (наприклад, розширення моделі вкладених транзакцій з допомогою доповнення її компенсирующими транзакціями чи оперативне зміна правил обробки вкладених транзакций).

— Безпека. Безпека вимагає охоплення всіх ресурсів середовища (мережу, операційна система, СУБД). Монітори TP наступного покоління мають включати розширені кошти безпеки, зокрема підтримку багаторівневої захисту даних, які зберігаються єдиної среде.

— Масштабованість. Архітектура обробки транзакцій, оптимальна для 100 вузлів, може бути неефективною для середовища з 1000 чи 10 000 вузлів. Монітори TP нового покоління ще повинні мати властивістю масштабируемости з урахуванням змінного числа і обсягу різних ресурсів (можливо, з допомогою згадуваних вище коштів підтримки расширяемости).

Заключение

.

Системи обробки транзакцій як і, як інші види інформаційних і комп’ютерних систем, нині напівживі постійного розвитку. Попри те що що концепцію, наприклад, вкладених транзакцій була вироблено ще на початку 80-х, коли раніше, проте недавно моделі транзакцій, прогресивніші, ніж найпростіші плоскі, почали переміщатися з експериментальних систем у великі комерційні продукты.

Розвиток сфери обробки транзакцій неминуче визначатиметься такими чинниками, як розподіленість обчислювальних ресурсів немає і потреба у межоперабельности. Через це, соціальній та силу те, що організації дедалі активніше шукають кошти на об'єднання і забезпечення керованості своїх інформаційних ресурсів, зростатиме значення зусиль, вкладених у підтримку стандартизації, зокрема реалізацію продуктів TP, інтегрованих з середовищем DCE, сумісних зі специфікаціями OSI-TP, X/Open DTP.

Перспективы.

Краткосрочные.

— Зростання числа продуктів, підтримують розвинені моделі транзакцій (вкладених і/або многозвенных).

— Формалізація специфікацій X/Open DTP і реалізація сумісних з ними продуктов.

Долгосрочные.

— Поява комерційних версій моніторів TP третього покоління, інтегрованих з дисципліною потоків робіт, із підтримкою довгострокових транзакцій та інших прогресивних средств.

Практичні выводы.

Кошти обробки транзакцій яких багато важать підтримки цілісності корпоративної інформації. Хоча у галузі досліджень складних моделей транзакцій досягнуто значні результати (зокрема, вироблені парадигми, найприйнятніші для розподілених систем, ніж застосовували надувалася протягом багатьох років у централізованих оточеннях мэйнфреймов), але вони лише тепер починають знаходити використання у реальних приложениях.

Ключовим властивістю складних моделей транзакцій є можливість розбивати транзакцію на компоненти (субтранзакции). Субтранзакции, в залежність від конкретної моделі обробки, може бути: (1) перезапущены при рестарте системи без необхідності наново виконувати всю транзакцію з початку; (2) оброблені одночасно чи асинхронно щодо інших субтранзакций; (3) підпорядковані деякою «верховної (master) транзакції «, має право перервати будь-яку зі своїх субтранзакций, навіть якщо та як така нормально завершила свій шматок обработки.

Найважливіше тенденція у сфері обробки транзакцій — зародження стандартів у двох областях: формати і протоколи (т. е. стандартизація наборів пересланих повідомлень і реакцій одержувача за кожен тип повідомлення), і навіть прикладні програмні інтерфейси (АПІ); усе це сприяє забезпечення мобільності додатків обробки транзакцій щодо різних платформ.

Що дає ця технология.

У зв’язку з новими потребами сильно розподілених оточень що час переглянути багато усталені ставлення до моделях обробки транзакцій, хто був вироблені для централізованих оточень мэйнфреймов. Моделі одноуровневого управління не годяться для ситуації, як у обробку транзакції залучено безліч процесорів; є безліч способів групування субтранзакций на підтримку функціонування складних окружений.

Важливе значення має тут правильний вибір одній з складних моделей обробки транзакцій з огляду на специфіку діяльності конкретної організації. Наприклад, вкладені транзакції надають виключно гнучкі способи управління субтранзакциями, але дуже складні в реалізації; у своїй ні в першій-ліпшій нагоді такі можливості справді необхідні. У деяких ситуаціях цілком прийнятною може бути модель многозвенных транзакцій, особливо якщо бизнес-функциям даної організації відповідають схема асинхронної обробки субтранзакций.

Наголосимо також на, що він практично будь-якого фахівця у сфері ІВ треба добре орієнтуватися у різних стандартах обробки транзакций.

1. У. Дайял. Монітори транзакцій третього покоління, 1993.

2. Дж. Грей і A. Реутер. Транзакції: Лекції і практика. — Сан Франциско: Морган Кауфман, 1993.

3. A. Д. Вольф, Дж. Транскар. Монітор транзакцій Encina. У листопаді, 1992.

4. Интернет.