Зміст

Введення ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. ... ... ... ... ... ... ... .... 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3. Багатоланкові транзакції

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Малюнок 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, відповідає ступенюрозподіленості, характерної для розроблюваних або проектуються уданий час інформаційних систем. Використання серверів додатківтут відповідає філософії виділення процедур обробки даних, ввідміну від філософії виділення самих даних. Хоча користувачі, які маютьдостатні повноваження, можуть безпосередньо здійснювати доступ довіддаленим даними, але в даному випадку мета полягає в тому, щоб повністюпередати керування даними серверів додатків.

Малюнок 6. Відкрита прикладна середу розподіленої обробки транзакцій.

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

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

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

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

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

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

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

4. X/Open DTP

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

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

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

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

Стандарт API розроблений комітетом X/Open і отримав назву X/Open
Distributed Transaction Processing (DTP) API. 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.

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

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

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

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

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

H - ступінь неоднорідності машин та програмного забезпечення; < p> D - безліч логічних даних;

S - безліч вузлів.

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

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

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

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

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

Значення цих коштів визначається частково тим, що вони сприяютьінтеграції концептуального моделювання процесів і даних. Класичніпроцедури інтеграції 1970-х років орієнтувалися, наприклад, на відображеннядіаграм потоків даних (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) транзакції",яка має право перервати будь-яку зі своїх субтранзакцій, навіть якщо тасама по собі нормально завершила свою частину обробки.

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

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

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

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

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

Література

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

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

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

4. Інтернет.