Обработка транзакций (стр. 3 из 4)

Рисунок 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 - степень неоднородности машин и программного обеспечения;

D - множество логических данных;

S - множество узлов.

Эта классификация характеризует любую систему обработки транзакций, от простейших (P1, M1, H1, D1, S1) до более сложных многоузловых неоднородных окружений с поддержкой разнотипных наборов данных (Pn, Mn, Hn, Dn, Sn). В статье, написанной в 1991 г., эти авторы представили трехмерную классификацию, которую они применили для оценки различных исследовательских и коммерческих систем.

6. Языки транзакций

В разд. 4 была рассмотрена Encina - монитор транзакций корпорации Transarc - который включает множество библиотек и макросов, составляющих среду разработки Transactional C. Альтернативный способ задания директив обработки транзакций состоит в применении специального языка. В качестве примера рассмотрим язык InterBase Parallel Language (IPL), входящий в состав неоднородной распределенной cреды баз данных 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) вместе с процедурами и представлениями данных, необходимыми для реализации комбинированной модели "потоки работ - транзакции - данные".