Модель обработки транзакций

Модель X/Open DTP описывает взаимодействие трех субъектов обработки транзакций - прикладной программы (в качестве прикладной программы фигурирует как AS, так и АС), менеджера транзакций (Transaction Manager - TM) и менеджера ресурсов (Recource Manager - RM).

На RM возложено управление информационными ресурсами - будь то файлы, базы данных или что-то другое. Прикладная программа взаимодействует с RM либо с помощью набора специальных функций, либо, если в качестве RM выступает реляционная SQL-ориентированная СУБД - посредством операторов языка SQL, инициируя необходимые операции с данными. Последние оформляются как транзакции, обработку которых берет на себя ТМ. Если с помощью монитора транзакций необходимо решать задачи обработки глобальных транзакций, то место менеджера ресурсов должна занять СУБД, поддерживающая протокол двухфазовый фиксации транзакций и удовлетворяющая стандарту X/Open XA (например, Oracle 7.0, Open INGRES, Informix-Online 5.0).

Роль ТМ в модели X/Open DTP - роль диспетчера, главного координатора транзакций. Он обладает полным набором управления как локальными, так и глобальными транзакциями. В последнем случае транзакция может обновлять данные на нескольких узлах, причем управление данными на них осуществляется, вообще говоря, различными RM. Обработки распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации транзакций, который гарантирует целостность данных в информационной системе, распределенной по нескольким узлам, независимо от того, какой RM управляет обработкой данных на каждом таком узле. Эта уникальная возможность мониторов транзакций как раз и позволяет рассматривать их как своего рода "клей", как средство интеграции в гетерогенной информационной среде.

Понятия транзакции в ТРМ и в традиционных СУБД значительно отличаются. Суть остается одной ("все или ничего"), но в понимании СУБД транзакция - это атомарное действие над базой данных, в то время как в ТРМ транзакция трактуется гораздо шире. Она включает не только операции с данными, но и любые другие действия - передачу сообщений, запись в индексированные файлы, опрос датчиков и т. д. Это позволяет реализовать в ТРМ прикладные транзакции, бизнес-транзакции, что в СУБД, вообще говоря, сделать невозможно.

Функции ТРМ в модели X/Open DTP не ограничиваются только управлением транзакциями. Он берет на себя также координацию взаимодействия клиента и сервера (поэтому иногда его называют Transaction & Communication Manager). При этом используется высокоуровневый интерфейс ATMI (Application Transaction Monitor Interface), представляющий собой набор вызовов функций на языке третьего поколения (например, на языке С). С его помощью разработчик реализует один из нескольких режимов взаимодействия клиента и сервера в рамках расширенной модели "клиент-сервер". Ни AS, ни АС не содержат явных вызовов менеджера транзакций - они включены в библиотечные функции ATMI и невидимы извне. Таким образом, детали взаимодействия прикладной программы и монитора транзакций скрыты от разработчика, что и дает основание говорить об ATMI как о высокоуровневом интерфейсе.

Стандартный способ передачи данных между AC и AS - буфера данных. Они представляют собой определяемые разработчиком структуры данных, память под которые выделяется ТМ. В процессе передачи данных ТМ выполняет различные преобразования (например, согласует формат представления данных при передаче их между машинами с разными архитектурами).

Модель X/Open DTP не описывает в деталях структуру монитора транзакций. Она лишь определяет, из каких компонентов должна состоять любая система DTP и как эти компоненты взаимодействуют друг с другом. Будучи воплощенной в конкретной системе, модель дополняется возможностями, существенно расширяющими традиционные представления о технологии "клиент-сервер". Например, монитор транзакций TUXEDO позволяет организовать взаимодействие АС и AS несколькими способами.

С помощью синхронного вызова tpcall() АС вызывает конкретную службу (один из параметров - имя службы), передает ей исходные данные в буфере и немедленно получает от службы результат обработки. Асинхронный вызов (функция tpcall()) делает то же самое, с тем лишь отличием, что результат обработки возвращается не сразу; клиент запрашивает службу для получения результатов обработки вызовом tpgetrply(). Асинхронный способ взаимодействия позволяет клиенту передать серверу запрос, продолжить работу и получить результаты запроса самостоятельно и в нужный момент времени. Кроме того, поддерживается диалоговый режим взаимодействия, позволяющий сохранять его контекст от сообщения к сообщению. Клиент подключается к серверу (вызов tpconnect()), получая его в монопольное использования до момента окончания диалога (вызов tpdiscon()). Наконец, существует вариант обмена сообщениями между клиентом и сервером через хранимые на диске очереди.