Ю. А. Григорьев, Г. И. Ревунков - Банки данных

	13. Выбор общесистемных пакетов
	Pentium		мальной	производительности						об­
			работки	данных			при		невысоких
Ряд1	DOS, MS Windows		стоимостных			показателях,				под­
			держка целостности данных в гете­
			рогенной среде. ТРМ опираются на
	Unix		трехзвенную модель клиент/сервер
			(модель сервера приложений). Ес­
Ряд 2	ТРМ	1(менеджер^^^^	тественно,		что	все		преимущества
			модели	отражаются				и на		про­
			1		системах,			построенных
	Шлюз	ресурсов)	граммных
			на ее основе.
			На	современном					рынке	мо­
			ниторов	транзакций					основными
			«действующими лицами» являются
			такие системы, как ACMS (DEC),
	Мэйнфреймы		CICS (ЮМ), ТОР END (NCR),
РядЗ	(или RISC-системы		PATHWAY		(Tandem),				ENCINA
	с ОС Unix)		(Transarc), TUXEDO System (USL —
Рис. 13.3. Корпоративная среда обработки			разработчик, BEA System — владе­
			лец этого продукта). Несмотря на
	транзакций ЕТР		принципиальное				сходство,			кон-

кретные ТРМ отличаются рядом характеристик, причем различия часто вытекают из специфики операционной системы, в которой реализован и функционирует ТРМ. Ниже описаны основные возможности ТРМ на базе ОС Unix.

ТРМ на базе ОС Unix опирается на фундаментальное понятие — кор­ поративную среду обработки транзакций (Enteфrise Transaction Processing - ЕТР). Архитектура ЕТР — это три ряда компьютеров (рис. 13.3):

•ряд 1: персональные станции (Personal Workstations);

•ряд 2: компьютеры под управлением ОС Unix (Unix Transaction Processing Servers — UPTS);

•ряд 3: Mainframe-системы (Proprietary Transaction Processing Servers — PTPS) или компьютеры под управлением Unix с RISC-архитектурой процес­ соров.

Таким образом, среда обработки транзакций формируется из набора разнородных компьютеров (и соответствующих ОС), ранжируемых от пер­ сональных компьютеров до мэйнфрейм-систем. ТРМ на базе ОС Unix пред­ ставляет своего рода «клей», который связывает вместе компьютеры трех рядов в открытую унифицированную среду обработки транзакций.

Ключом к интеграции систем, функционирующих на компьютерах различных рядов, является специализированный интерфейс прикладного программирования ATMI (Application Transaction Manager Interface), обес­ печивающий:

270

13.2.Варианты выбора распределенной СУБД

•для ряда 1 — формирование и передачу запросов от клиентов к сер­ верам, выполняющимся на компьютерах ряда 2;

•для ряда 2 — обработку запросов, поступающих от компьютеров ря­ да 1 (в том числе и с обращениями к менеджеру ресурсов), и, при необхо­ димости, формирование и направление запросов к серверам, выполняю­ щимся на компьютерах ряда 3;

•для ряда 3 — обработку запросов, поступающих от серверов ряда 2. ТРМ целесообразно использовать в следующих случаях:

•необходимо, чтобы система автоматически выполняла маршрутиза­ цию запросов к распределенным сервисам-приложениям (см. ниже Tuxedo);

•имеет место большая интенсивность обращений рабочих станций к общим прикладным программам (бизнес-правилам);

•используются маломощные рабочие станции и низкоскоростные сети.

Х/Ореп ОТР-иитерфейс с монитором траизакг{1ш. Понятия транзак­

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

ТРМ опирается на модель (стандарт) обработки распределенных тран­ закций Х/Ореп DTP, которая описывает взаимодействие трех субъектов обработки транзакций — ПП (в качестве ПП фигурирует как сервер прило­ жения, так и клиент приложения), менеджера транзакций (Transaction Mana­ ger — ТМ) и менеджера ресурсов (Resource Manager — RM) — рис. 13.4.

На RM возложено управление информационными ресурсами (файлы, БД или что-то другое). Приложение взаимодействует с RM либо с помощью набора специальных функций, либо, если в качестве RM выступает реляци­ онная SQL-ориентированная СУБД, посредством языка SQL, инициируя необходимые операции с данными. Последние оформляются как транзак­ ции, обработку которых берет на себя ТМ. Если с помощью ТМ необходимо решать задачи обработки распределенных транзакций, то роль RM должна выполнять СУБД, поддерживающая двухфазовый протокол фиксации тран­ закции и удовлетворяющая стандарту Х/Ореп ХА (например, Oracle 7.x, OpenlNGRES, Informix-OnLine 7.x).

Назначение ТМ в модели Х/Ореп DTP — выполнять роль диспетчера, главного координатора транзакций. Он обладает полным набором функций управления, как локальными, так и глобальными, распределенными тран­ закциями. В последнем случае транзакция может обновлять данные на не­ скольких узлах, причем управление данными на них осуществляется раз­ личными RM. Обработка распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации транзакций, который

271

13. Выбор общесистемных пакетов

Прикладная программа

ATMI

Менеджер ресурсов ^	ХА
	>^
ч.	^
Oracle

Монитор

транзакций

Sybase

Informix

Рис. 13.4. Х/Ореп DTP-интерфейс

гарантирует целостность данных в ИС, распределенной по нескольким уз­ лам, независимо от того, какой RM управляет обработкой данных на каж­ дом узле. Эта уникальная возможность как раз и позволяет рассматривать ТРМ как средство интеграции в гетерогенной информационной среде.

Функции ТМ в модели Х/Ореп DTP не ограничиваются только управ­ лением транзакциями. Он выполняет также координацию взаимодействия клиента и сервера (поэтому ТРМ иногда называют менеджером транзакций и коммуникаций). При этом используется высокоуровневый интерфейс ATMI (см. выше), представляющий набор вызовов функций на языке третьего поко­ ления (например, на языке С). С его помощью разработчик реализует один из нескольких режимов взаимодействия клиента и сервера в рамках расширен­ ной модели клиент/сервер. Ни сервер приложений, ни клиент приложения не содержат явных вызовов менеджера транзакций — они включены в библио­ течные функции ATMI и невидимы извне. Таким образом, подробности взаи­ модействия ПП и монитора транзакций скрыты от разработчика, что и дает основание говорить об ATMI как о высокоуровневом интерфейсе.

Модель Х/Ореп DTP не описывает в деталях структуру ТРМ. Она лишь определяет, из каких компонентов должна состоять система и как эти компоненты взаимодействуют друг с другом. Будучи воплощенной в кон­ кретной системе, модель дополняется возможностями, существенно расши­ ряющими традиционные представления о технологии клиент/сервер.

Менеджер транзакций Tuxedo. Схема функционирования Tuxedo. На рис. 13.5 приведена схема взаимодействия клиентов, менеджера транзакций (ядра сервера приложений) и менеджера ресурсов (сервера СУБД).

272

J3.2. Варианты выбора распределенной СУБД

	Клиент	Сервер приложения			Сервер СУБД
WS
	Программа	Менеджер транзакций			Менеджер
		Tuxedo System/T			ресурсов
	на 4GL
с	X/	Очереди запросов	Приложение
	ATMI	к сервисам
	tpcallC'A",...);
	tpcallC'B",...);			Процесс
	tpcallC'C",...);			(сервер)	ХА
				SRV1
		D D	rt	Сервис А
				Сервис В	Сервер
WS			"^Сервисе		СУБД
	программа	Доска объявлений		Процесс
		(список сервисов)		(сервер)
	Ha4GL			SRV2

	Сервис D
А, В, С, D, Е	Сервис Е
tpcallC'D",...);
tpcallC'E",...);

Рис. 13.5. Схема взаимодействия клиента, сервера приложений и СУБД

Обращения клиентов к менеджеру транзакций (ТМ) выполняется из программ, написанных на языке С. Поэтому для обращения к ТМ Tuxedo (ВЕА System) из программ на языке 4GL необходимо создать промежуточ­ ный модуль на языке С. Связь между клиентом и менеджером транзакций организуется на базе интерфейса ATMI. В качестве клиента ТМ может так­ же выступать менеджер транзакций, функционирующий на другом сервере.

Приложение представляет совокупность параллельно выполняемых процессов (серверов). Каждый процесс — это программа на языке С, со­ стоящая из функций (сервисов). Программа клиента с помощью вызова tpcall обращается именно к сервису. При этом запрос клиента помещается в очередь к сервису. Специальный системный процесс менеджера транзакций TMQFORWARD извлекает запрос из очереди и направляет его сервису. Для выполнения запроса создается внутренний поток, связанный с процессом, который содержит этот сервис. Сервис обрабатывает вызов, обращаясь для

273

13. Выбор общесистемных пакетов

этого к серверу СУБД (интерфейс ХА) командами EXEC SQL. Сервис, вы­ полнив предписанные действия и сформировав запрос на ответ в виде со­ общения, посылает его в очередь ответов, откуда это сообщение передается клиенту для обработки.

Возможность хранения очередей сообщений в долговременной памя­ ти позволяет говорить о почти стопроцентной надежности взаимодействия клиента и менеджера транзакций. Даже в случае сбоя компьютера все со­ общения с точностью до последнего сохраняются, а их обработка возобнов­ ляется с той точки, где произошел сбой. Любые действия с очередями по­ мещаются в файл транзакций, что обеспечивает полную надежность при доставке сообщений, позволяет доставлять сообщения с уведомлением о получении и реализовать множество полезных функций, необходимых в коммуникационных системах.

Настройка и запуск монитора транзакций. Описание приложения Tuxedo содержится в его конфигурационном файле. Важно отметить, что вся информация об архитектуре приложения вынесена из кодов приложения и сконцентрирована в конфигурационном файле. Это — важнейший прин­ цип Tuxedo System, позволяющий настраивать приложение, не затрагивая его кодов. В табл. 13.5 приведены структуры наиболее важных секций кон­ фигурационного файла приложения Tuxedo.

Таблица	13.5. Структура конфигурационного файла
	приложения Tuxedo
Секции и их параметры	Описание
•RESOURCES	Имя секции ресурсов
IPCKEY код	Некоторое значение, идентифицирующее выделяе­
	мые приложению IPC-ресурсы
MASTER имя_узла	Идентификатор текущего узла, на котором выполня­
	ется менеджер транзакций приложения
MAXACCESSERS число	Число процессов, которые могут одновременно об­
	ращаться к очередям запросов
MAXSERVERS числа	Общее число серверов (процессов, см. рис. 13.5)
	приложения (до 32768)
MAXSERVICES число	Общее число сервисов приложения (до 32768)
MODEL SHM или MP	Модель приложения:
	SHM — менеджер транзакций и приложение выпол­
	няются на одном компьютере,
	MP — многомашинная конфигурация
LDBAL Y или N	Выполняется (у) или не выполняется (N) баланс за-
1	грузки

274

13.2. Варианты выбора распределенной СУБД

	Продолжение табл. 13.5
Секции и их параметры	Описание
•MACHINES	Секция описания компьютерных узлов, на которых
	выполняются менеджер транзакций и приложение
DEFAULT:	Полный путь к каталогу, содержащему исполняемые
APPDIR путь
	коды приложения
TUXCONFIG путь	Полный путь к бинарному конфигурационному файлу
ROOTDIR путь	Полный путь к корневому каталогу менеджера тран­
	закций Tuxedo
имя ЬМГО=имя_узла	Эта и последующие строки секции описывают сете­
	вые имена компьютеров и идентификаторы узлов, на^
	которых выполняется менеджер транзакций и при­
	ложение
•GROUPS	Секция описания групп процессов (серверов)
имяфуппы	Идентификатор группы процессов и идентификатор
ЬМГО=имя_узла	узла, где выполняются процессы
GRPNO=HOMep	Номер группы процессов
TMSNAME=имя	Имя сервера управления транзакциями
OPENINFO=CTpoKa	Строка, определяющая вызываемый приложением
	менеджер ресурсов, участвующий в распределенной
	транзакции
•SERVERS	Секция описания процессов (серверов)
DEFAULT:	Параметры, общие для всей секции. CLOPT опреде­
CLOPT=CTpoKa	ляет командную строку, передаваемую процессу
имяпроцесса	Имя процесса (модуля) и ссылка на идентификатор
SRVGRP=имя_гpyппы	группы процессов
SRVID=нoмep_пpoцecca	Номер процесса в группе
•SERVICES	1 Секция описания сервисов (функций процессов),
DEFAULT:	которые выставляются на доску объявлений
	Определяемые по умолчанию
LOAD=чиcлo	показатель загрузки,
PRIO=чиcлo	приоритет сервиса
имясервиса	Определяет имя сервиса процесса и необязательные
	параметры:
LOAD=чиcлo	показатель загрузки для сервиса.
РЮО=число	приоритет сервиса.
ROUTING=имя_пpaвилa	имя правила в секции маршрутизации • ROUTING

275

13. Выбор общесистемных пакетов
	Окончание табл. 13.5
Секции и их параметры	Описание
•ROUTING	Секция описания правил автоматической маршрути­
	зации запросов к сервисам
имяправила	Определяет имя правила и следующие параметры:
Р1ЕЬВ=имя_поля	имя проверяемого поля в буфере, передаваемом от
	юхиента,
BUFTYPE=«THn»	тип этого буфера (FML или VIEW),	i
RANGES= «
знач. 1-знач.2:	интервал значений проверяемого поля и группу про­
имяфуппы 1,	цессов, а поэтому и узел, которому передается запрос
	к сервису, если значение поля во входном буфере
знач.З-знач.4:	находится в этом интервале,
	другой интервал значений проверяемого поля и т.д.
имя_группы2,

Конец строки RANGES

Пример конфигурационного файла приведен ниже, где обсуждается вопрос маршрутизации запросов.

Для приложения Tuxedo определены две основные операции: старт (выполняется утилитой tmboot()) и останов (выполняется утилитой tmshutdownO). Перед стартом конфигурационный файл должен быть откомпили­ рован в бинарный формат. Компиляция выполняется утилитой tmloadcf(). В процессе компиляции проверяется корректность конфигурационного файла и взаимное соответствие значений параметров. Старт приложения происхо­ дит следующим образом. Tuxedo System/T запрашивает у ОС Unix необхо­ димые приложению IPC-ресурсы, загружает параметры приложения из от­ компилированного конфигурационного файла в разделяемую память, раз­ мещает в разделяемой памяти служебные структуры, запускает служебные процессы System/T и серверы (процессы) приложения. Сегмент разделяемой памяти, где System/T размещает служебные структуры и параметры прило­ жения, носит название «Доска объявлений» (Bulletin Board). В частности, System/T выставляет на Доску объявлений имена доступных в приложении сервисов. Доска объявлений обслуживается служебным процессом System/T под названием BBL (Bulletin Board Language).

Успешное завершение tmboot() означает, что приложение стартовало и готово к работе, и для клиентов приложения доступны его сервисы. Отме­ тим, что клиенты адресуют в своих запросах только сервисы, не указывая серверы, содержащие эти сервисы. Внутреннее устройство приложения не­ видимо клиентам. Более того, им невидимо и расположение приложения —

276

13.2, Варианты выбора распределенной СУБД

на каком из узлов сети оно выполняется, им ничего не известно об исполь­ зуемых приложением менеджерах ресурсов. Следовательно, можно считать, что между клиентом и сервисами система System/T образует информацион­ ную шину: клиенты напрявляют в нее запросы, адресуя их конкретным сер­ висам, ответы на запросы клиент также получает из информационной шины.

Стартовав, приложение функционирует до тех пор, пока не будет вы­ полнена утилита tmshudownO, либо пока не будет остановлен компьютер, на котором она выполняется. Работой активного приложения можно управ­ лять. Утилита tmadminO позволяет опрашивать параметры состояния при­ ложения: получать информацию об активных клиентах приложения, об оче­ редях сообщений, о загрузке сервисов. Более того, можно вмешиваться в работу приложения, например приостанавливать выполнение отдельных сервисов или переносить отдельные компоненты приложения (серверы, группы серверов) или все приложение целиком на дублирующий узел сети. Этот процесс называется миграцией. Начиная с версии 6.0, используется утилита администрирования xtuxadm(), предоставляющая графический ин­ терфейс (в рамках Motif) для доступа к параметрам приложения, пришед­ шая на замену tmadmin().

Понятие миграции необходимо пояснить. Дело в том, что для прило­ жения может быть определен так называемый разделяемый режим функ­ ционирования. В нем для приложения определено два узла: основной и дуб­ лирующий (информация об этих узлах, в том числе и их сетевые адреса, заносится в конфигурационный файл). При необходимости (например, если требуется вывести основной узел из эксплуатации на время профилактиче­ ских работ) администратор приложения запускает процесс миграции всего приложения или отдельных его компонентов (серверов или их групп) на дублирующий узел. Важно, что миграция компонентов приложения выпол­ няется вместе с контекстом их окружения: набором объявленных сервисов, очередями сообщений и т.д. Фактически, Доска объявлений основного узла в процессе миграции точно воспроизводится на дублирующем узле.

Важной особенностью Tuxedo System, отсутствующей у других менед­ жеров транзакций (Encina, TopEnd), является возможность программного доступа к параметрам приложения на Доску объявлений. Набор актуальных данных о Приложении (данные из конфигурационного файла плюс оператив­ ная информация о приложении) называется базой данных управления (Man­ agement Information Base — MIB). Доступ к MIB и оперативное изменение значений параметров приложения могут осуществляться из программы, при­ чем для обращения к параметрам приложения в MIB используют стандартные вызовы библиотеки Tuxedo ATMI. Используя базу данных управления и ком­ поненту Tuxedo/Admin (начиная с версии 6.0), разработчик может создать собственные программы мониторинга и диспетчеризации приложения.

Типизированные буферы, интерфейс прикладного программирования ATMI. Взаимодействие клиента и сервера невозможно без структуризации и

277

13. Выбор общесистемных пакетов

обмена данными. Обращаясь с запросом к серверу, клиент должен передать ему исходные данные и получить результат. Tuxedo System позволяет ис­ пользовать традиционные средства языка С — структуры. Взаимодействие клиента и сервера можно организовать, передавая данные в структурах, но это нерационально. Дело в том, что любые изменения в структурах (добав­ ление новых полей, исключение старых) требуют перекомпиляции исполь­ зующих их программ. Кроме того, если данные из структур хранятся в фай­ лах, то такие изменения также требуют реорганизации файлов. Размер эле­ ментов структур и их смещение в структуре фиксированы, это вызывает избыточный расход памяти, так как далеко не в каждый момент времени элементы структур содержат конкретные значения и очень часто в них на­ ходится «мусор».

В Tuxedo System разработан специальный механизм структуризации данных. Речь идет о структурированных и типизированных (fielded) буфе­ рах. Структурированный буфер представляет коллекцию значений имено­ ванных полей. Главные преимущества структурированных буферов в срав­ нении со структурами в терминах С — это независимость данных от про­ граммы, гибкость и легкость модификации. Поля могут быть добавлены в буфер, удалены из него, может быть изменен размер поля — и все это про­ изводится без перекомпиляции программ, работающих с буфером. Доступ к буферам и их полям осуществляется посредством конструкций языка мани­ пулирования полями (Field Manipulation Language — FML).

FML реализован как библиотека функций, доступных из С-программ. Структурированные буфера Tuxedo часто для простоты называют FMLбуферами. В настоящий момент FML-буфер — это унифицированное сред­ ство для представления данных в системе с архитектурой клиент/сервер. Клиент и сервер, взаимодействуя друг с другом, манипулируют FML-буфе- рами и передают через них данные. FML-библиотека содержит три группы функций. Первая группа включает функции создания и обновления буферов и выборки из них данных; во вторую входят функции преобразования типов данных в FML-буферах; третья состоит из функций преобразования данных из FML-буферов в структуры С. Поясним последнюю группу.

Если для передачи данных между клиентом и сервером использу­ ются FML-буфера, то работу программ с данными можно организовать двумя способами. Первый способ предполагает для доступа к данным в FML-буфере использовать исключительно функции первой группы — данные в буфере доступны программе только через них (например, функция fget() позволяет получить из FML-буфера значение поля с ука­ занным именем). Второй способ позволяет преобразовать структуры С в FML-буферы и обратно. Для этого используются так называемые VIEWS-функции.

Если вы хотите использовать для транспортировки данных FMLбуфер, то необходимо определить его в текстовом файле:

278

13,2. Варианты выбора распределенной СУБД

#name	rel-number	type	flags	comments
EMPNAME	1	siring		emp name
EMPID	2	long		emp id
EMPJOB	3	char		job type
EMPADDR	4	string		street address
EMPCITY	5	string		city
EMPSTATE	6	string		state
EMPZIP	7	int		zip code

Нетрудно увидеть, что описание FML-буфера схоже с описанием таблицы в реляционных БД. Для каждого поля FML-буфера определяет­ ся его имя, по которому к полю будет осуществляться доступ (колонка name), относительный номер поля в буфере (колонка rel-number), тип поля (колонка type). Колонка comments предназначена для комментари­ ев, а колонка flags — для использования в будущем. Любое поле может иметь один из базовых типов: char, short, float, double, string, carray (мас­ сив символов).

Описания FML-буфера в текстовом файле достаточно для того, чтобы клиент и сервер обращались к соответствующему FML-буферу и размещали в нем или выбирали из него данные. Для этого должны быть определены две переменные окружения — FLDTBLDIR (имя каталога, где лежит файл с описанием FML-буфера) и FILETBLS (имя самого файла). Если вы хотите иметь описания полей непосредственно в тексте программы-клиента или программы-сервера, необходимо воспользо­ ваться утилитой mkfldhdrO, которая конвертирует описание буфера в файл <имя файла описания бyфepa>.h. Полученный файл содержит для каждого поля буфера строку:

#define fname fieldid

где значения fieldid извлекаются из описания буфера. Этот h-файл может быть использован в программе (клиент, сервер) для последующей компиляции.

FML-буфера — мощное и удобное унифицированное средство для транспортировки данных между клиентом и сервером. В большинстве при­ ложений на основе Tuxedo применяют преимущественно FML-буфера. Кроме них. Tuxedo позволяет работать с буферами типа STRING (содержит строку символов, заканчивающуюся NULL) и CARRAY (содержит массив символов, каждый из которых может быть нулевым). Буфер типа VIEW используют для двух целей: для преобразования FML-буферов в структуры языка С и обратно или непосредственно для передачи содержимого струк­ туры С между клиентом и сервером.

Прежде чем использовать буфер в программе, необходимо выделить под него память при помощи вызова tpalloc(), например:

279