Tuxedo System — ключевой компонент корпоративных информационных систем

Средства разработки

Несколько слов о средствах разработки систем с трехзвенной архитектурой "клиент-сервер" на основе Tuxedo System. Читатель обратит внимание на приводимые ниже примеры, которые представляют собой программы на языке C. Предвидя замечания со стороны разработчиков — "Это что же, нам придется все писать на C?" — автор должен сделать следующее разъяснение.

Действительно, если мы планируем использование только Tuxedo System, то приложение придется разрабатывать на одном из трех языков — C, C++ или COBOL. В то же время клиенты приложения можно создавать с помощью любых средств разработки (PowerBuilder, SQL Windows, VisualBasic, CA-VisualObjects) - важно, чтобы из программ можно было вызывать C-функции. Программы-клиенты приложения можно разрабатывать для использования в операционных средах DOS, MS-Windows, MacOS, OS/2, UNIX, Windows NT.

Таким образом, проблема ускорения разработки за счет использования языков четвертого поколения (4GL) состоит только в выборе систем проектирования и реализации серверов приложения.

Таких систем немного, но они существуют. Из известных можно выделить систему MAGNA X американской компании MAGNA X Software, позволяющую автоматизировать процесс проектирования и реализации сервисов. В составе MAGNA X имеются средства, позволяющие генерировать сервисы на основе подготовленного проектировщиком графического описания приложения. В результате порождаются коды сервисов на языке четвертого поколения, разработанном MAGNA X Software и получившем название XPL. Коды сервисов на XPL компилируются в COBOL- или C-коды, из которых получается исполняемый код приложения. Таким образом, если кому-либо необходимы средства разработки сервисов на языке 4GL, то они существуют и их можно использовать.

Несколько замечаний о терминологии. В настоящий момент вместо устаревшего "монитор обработки транзакций" для определения Tuxedo используется термин "менеджер распределенных транзакций", что более соответствует профилю продукта. В то же время правильно было бы расширить это определения до "менеджер распределенных транзакций и коммуникаций" (ниже будет пояснено, почему это так). Говоря о серверах приложений, автор имеет в виду только программные компоненты (известно, что термин "сервер приложений" используется также и для определения компьютеров, на которых выполняется приложение, разделяемое многими пользователями).

Основные понятия

Ключевым понятием в Tuxedo System является приложение (трактовка отличается от общепринятой). Для того, чтобы объяснить его, необходимо сказать несколько слов о модели сервера приложений, на которую опирается Tuxedo System.

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

В соответствии с этим в любом приложении выделяются следующие логические компоненты:

• компонент представления (presentation), реализующий функции первой группы;
• прикладной компонент (business application), поддерживающий функции второй группы;
• компонент доступа к информационным ресурсам (resource access) или менеджер ресурсов (resource manager), поддерживающий функции третьей группы.

Различия в моделях "клиент-сервер" определяются тремя факторами. Во-первых, тем, в какие виды программного обеспечения интегрированы каждый из этих компонентов. Во-вторых, тем, какие механизмы программного обеспечения используются для реализации функций всех трех групп. В-третьих — как логические компоненты распределяются между компьютерами в сети. Выделяется три подхода, реализованные в следующих моделях:

• модель доступа к удаленным данным (Remote Data Access — RDA);
• модель сервера базы данных (DataBase Server - DBS);
• модель сервера приложений (Application Server — AS).

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

Запросы к информационным ресурсам направляются по сети удаленному компьютеру (например, серверу базы данных). Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных.

DBS-модель cтроится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции реализованы в хранимых процедурах (stored procedure). Они хранятся непосредственно в базе данных и выполняются на компьютере-сервере базы данных (где функционирует и компонент, управляющий доступом к данным, то есть ядро СУБД).

В AS-модели процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за ввод и отображение данных (то есть реализует функции первой группы). Прикладные функции выполняются программами в рамках процессов, функционирующих на компьютере-сервере. Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается ровно тем же способом, что и в RDA-модели. Из прикладных компонентов доступны ресурсы различных типов — базы данных, индексированные файлы, очереди и др.

RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во-втором — интегрируется в компонент доступа к информационным ресурсам. Напротив, в AS-модели реализована классическая трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами (компонентом представления и компонентом доступа к информационным ресурсам).

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

Например, сервер банковского приложения предоставляет услуги "открыть счет", "зачислить на счет", "снять со счета" и т.д. Внешне сервер приложения выглядит как завершенный набор сервисов. С точки зрения внутреннего устройства сервер приложения — это программа, в рамках которой реализованы сервисы.

Любая другая программа, которая пользуется ими, рассматривается как клиент приложения (Application Client — AC). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. AC обращается с запросом к конкретному сервису, но не к AS, то есть серверы приложений обезличены и служат лишь своего рода "рамкой" для оформления сервисов. Запросы, поступающие от AC, выстраиваются в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами запросов (о механизмах обработки запросов будет рассказано ниже).

Клиент приложения трактуется более широко, чем компонент представления. Он может поддерживать интерфейс с конечным пользователем (тогда он является компонентом представления), может обеспечивать поступление данных от некоторых устройств (например, датчиков), может, наконец, сам по себе быть сервером приложения, предоставляя услуги другим программам. То есть пара "клиент приложения — сервер приложения" динамична: сервер приложения, предоставляя услуги другим программам, сам может обращаться к услугам другого сервера приложения, и в этот момент он рассматривается как клиент приложения.

Серверов приложений может быть несколько, и каждый из них предоставляет определенный набор услуг. Вообще, приложение в терминологии Tuxedo System представлено коллекцией серверов приложений, предоставляющих осмысленный с точки зрения прикладной области набор услуг, и клиентов приложений, которые за этими услугами обращаются. Для организации клиентов и серверов приложений предусмотрен специализированный интерфейс прикладного программирования (Application Programming Interface — API), который в Tuxedo System называется интерфейс "приложение- менеджер Транзакций" (Application — Transaction Manager Interface — ATMI).

Чтобы получить доступ из клиента приложения к одному из сервисов, предоставляемых AS, необходимо использовать одну из нескольких библиотечных функций, входящих в ATMI (все функции ATMI будут кратко описаны ниже в Разд. Tuxedo ATMI).

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

В результате мы получаем трехзвенную архитектуру прикладной системы (Рис. 1). Менеджер транзакций и коммуникаций (Transaction & Communication Manager - T&CM) — это программная система, обеспечивающая взаимодействие клиентов приложений, серверов приложений и менеджеров ресурсов (реляционных СУБД) и управляющая обработкой транзакций, определенных в клиентах и/или серверах приложений. Транзакция определена в программе (клиенте или сервере), если в этой программе некоторый фрагмент исходного кода, выполняющий набор операций, трактуемый как единое целое, открывается вызовом функции tpbegin() (начать транзакцию) и завершается вызовом tpcommit() (завершить транзакцию) или tpabort() (откатить транзакцию).

Любое взаимодействие трех субъектов ИС трехзвенной архитектуры происходит с ведома и при участии T&CM. Менеджер транзакций Tuxedo называется Tuxedo System/T или просто System/T. Клиент, сервер и менеджер ресурсов общаются посредством вызовов функций ATMI. Управляет этим процессом System/T. Пусть, например, клиент запрашивает конкретный сервис. Запрос передается Tuxedo System/T. System/T перенаправляет его серверу, в рамках которого реализован запрашиваемый сервис. Пусть клиент направляет System/T запрос "начать транзакцию". Новая транзакция фиксируется во внутренних структурах System/T (детали описаны в Разд. Управление транзакциями). System/T вызывает менеджер ресурсов через XA-интерфейс и передает ему директиву "начать транзакцию".

Ключевые возможности Tuxedo System

Tuxedo System — это многоплановый продукт. Прежде всего, конечно, это средство разработки систем с архитектурой "клиент-сервер" на базе модели сервера приложений. Спектр возможностей, предоставляемых Tuxedo System разработчику, определяется в первую очередь прикладным программным интерфейсом. В этом смысле Tuxedo — исключительно гибкий продукт, дающий в руки программисту (в рамках ATMI) мощные средства для организации эффективного взаимодействия клиента и сервера приложений. Работая с Tuxedo ATMI и желая получить приложение с заранее заданными характеристиками (например, по пропускной способности запросов), можно воспользоваться одним из десятка различных способов организации общения клиента и сервера (наиболее важные из них будут описаны в Разд. Расширенная модель "клиент-сервер").

С другой стороны, Tuxedo System — это все-таки специализированное средство для создания приложений оперативной обработки транзакций (On-Line Transaction Processing — OLTP). Этот класс приложений характеризуется исключительно интенсивным потоком относительно простых (коротких) транзакций, поступающих к менеджерам ресурсов (в большинстве случаев — к СУБД) от тысяч и даже десятков тысяч пользователей. Прикладные области OLTP - это телекоммуникационные системы (например, биллинговые системы), системы резервирования авиабилетов и мест в отелях, банковские и биржевые системы и т.д. В то же время сферой применения Tuxedo System является построение распределенных информационных систем. Tuxedo используется для разработки приложений, работающих с распределенными базами данных в неоднородной среде (это означает, что в рамках приложения выполняются распределенные транзакции, затрагивающие, например, базы данных Oracle и Informix). Традиционная сфера применения Tuxedo — создание систем высокой готовности (доступности) с заранее заданными (возможно, весьма жесткими), характеристиками.

Таким образом, Tuxedo System представляет собой универсальный инструмент для создания компактных, надежных, производительных и гибких распределенных прикладных систем для весьма широкого круга разноплановых задач. Исходя из базовых возможностей Tuxedo System (о них пойдет речь далее), строятся модели информационных систем для каждой из специфических сфер применения. Так, например, на основе Tuxedo System в комбинации с архитектурой Sun SPARCluster Parallel DataBase и Oracle Parallel Server создана модель системы высокой доступности (разработка имеется в Jet Infosystems).

Баланс загрузки

Уникальная возможность Tuxedo — динамическая настройка параметров системы для достижения требуемой производительности (баланс загрузки). Одним из "узких мест" в системах OLTP является скорость обработки запросов, поступающих от множества (сотен, тысяч и даже десятков тысяч) пользователей. Если в один момент времени большое число запросов поступает в адрес одного сервиса (любой сервис в каждый момент времени обслуживает ровно один запрос), то образуется очередь запросов, которую необходимо разгрузить максимально быстро. Для этого в Tuxedo System предусмотрена возможность запуска дополнительных процессов — копий сервера, предоставляющего затребованный в запросах пользователей сервис. Поскольку таким образом количество доступных копий требуемого сервиса увеличивается, постольку очередь запросов быстро разгружается - System/T выбирает запросы из очереди и направляет их копиям сервисов. Соответственно, сразу же уменьшается время отклика приложения и пользователи начинают получать ответ на запрос значительно быстрее.

Количество копий конкретного сервера устанавливается в параметрах приложения и может динамически изменяться программой-монитором приложений посредством MIB. Если оно устанавливается единожды при задании параметров приложения и после этого не изменяется, то речь идет о статическом балансе загрузки.

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

Разумеется, количество и интенсивность запросов может увеличиться до такой степени, что вычислительные ресурсы компьютера, на котором выполняются серверы приложения, будут полностью исчерпаны, и никакое тиражирование копий процессов не позволит увеличить пропускную способность приложения. Tuxedo System позволяет использовать в таких ситуациях вычислительные ресурсы других компьютеров, запуская на них копии серверов приложения и переадресуя им запросы к сервисам. Таким образом достигается так называемая матричная масштабируемость, то есть практически неограниченная возможность привлечения дополнительных свободных в данный момент времени вычислительных мощностей.

Для иллюстрации механизма баланса загрузки рассмотрим пример. Пусть приложение включает три сервера — S1 (SRVA, SRVB, SRVC), S2 (SRVA, SRVB, SRVC), S3 (SRVB, SRVC) (в скобках указаны сервисы, предоставляемые каждым сервером). Каждый сервис имеет некоторый показатель загрузки, отражающий объем вычислительных ресурсов, необходимых для его выполнения (для SRVA он составляет 50, для SRVB — 60, для SRVC — 70). Каждый сервер приложения также имеет показатель его загрузки; каждый раз, когда запрос передается на обработку серверу, показатель его загрузки увеличивается на показатель загрузки сервиса, которому этот запрос направлен.

Клиент приложения формирует запрос и направляет его серверу приложения. Tuxedo помещает запрос в очередь запросов, единую для всех трех процессов. Tuxedo извлекает очередной запрос и передает его на исполнение тому из трех процессов, который содержит адресуемый в запросе сервис. Если два и более процесса содержат один и тот же сервис, то Tuxedo направляет запрос тому процессу, у которого показатель загрузки меньше (Рис. 2). Таким образом, происходит автоматическое динамическое выравнивание загрузки процессов. Отметим, что в нашем примере процесс S2 идентичен процессу S1 - он предоставляет те же самые сервисы, что и процесс S1; процесс S2 запущен с целью разгрузки процесса S1; вообще говоря, копий процесса S1 может быть запущено несколько. Цель - увеличить пропускную способность сервера приложения, максимально разгрузив очередь запросов к нему. Количество одновременно запускаемых копий сервера приложения задается в параметрах приложения и может быть увеличено (или уменьшено) администратором приложения или специально разработанной программой-монитором приложения без остановки приложения.

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

Маршрутизация запросов

В системах с распределенными базами данных возникает задача автоматической маршрутизации запроса к базе данных, содержащей необходимую порцию информации. Tuxedo System предлагает эффективный механизм, называемый data routing (буквально переводится "маршрутизация данных", но, по сути, это именно маршрутизация запросов).

Предположим, что имеется распределенная банковская система, хранящая и обрабатывающая, помимо прочего, некоторые счета клиентов. Информация о счетах хранится в локальных базах данных, рассредоточенных по нескольким городам, где и живут клиенты. При этом информация о счетах с номерами 1-10000 хранится в базе данных в Москве, с номерами 10001-20000 — в Санкт-Петербурге, с номерами 20001-30000 — в Нижнем Новгороде и т.д. В этих городах находятся подразделения банка, идентифицируемые номером (Санкт-Петербург — 2, Москва — 3, Нижний Новгород — 5 и т.д.).

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

tpcall("ACCOUNT", &buf, ...)

System/T, пользуясь информацией о маршрутизации запроса и исходя из значения поля ACCOUNT_ID, направляет запрос на соответствующий компьютер, к базе данных, в которой хранится информация о счете с искомым номером (Рис. 3).

Запрос может быть направлен и другим сервисам (OPEN, CLOSE, WITHDRAW, DEPOSIT, INQUIRY), также предоставляемым серверами на компьютерах, которые находятся в различных городах. Маршрутизация запросов к ним выполняется и по значению поля BRANCH_ID. Например, в запросе

tpcall ("OPEN", &buf, ...)

на Рис. 3 буфер buf содержит поле BRANCH_ID (номер филиала банка), в соответствии со значением которого System/T направляет запрос тому или иному филиалу.

Для детального рассмотрения примера нам потребуется ввести понятие описания приложения, которое будет подробно разъяснено в Разд.

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

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

В секции *MACHINES описаны компьютеры, на которых выполняются серверы приложения (comp1, comp2 и т.д.). В секции *GROUPS представлены группы серверов (каждая группы выполняется на отдельном компьютере). На каждом таком компьютере работает СУБД (для групп BANK1, BANK3 — это Oracle, для BANK2 — Informix и т.д.) и хранится база данных с информацией о счетах клиентов. Обратим внимание на то, что на каждом из компьютеров comp1, comp2, comp3 функционирует менеджер ресурсов (то есть СУБД). Роль посредника между менеджером транзакций и каждым менеджером ресурсов в Tuxedo System выполняет специальный процесс, имя которого определяется параметром TMSNAME (процессам, отвечающим за взаимодействие с Oracle на узлах comp1 и comp2, присвоены различные имена — TMSORA и TMSORC, чтобы избежать ошибки).

Наконец, в секции *SERVERS описан сервер ACCNT, предоставляющий сервисы ACCOUNT, OPEN, CLOSE, INQUIRY, WITHDRAW, DEPOSIT (по сути, этот один и тот же процесс, выполняющийся на компьютерах comp1, comp2, comp3). Секция *SERVICES хранит описание (помимо прочих) сервиса ACCOUNT с параметрами — показатель загрузки (LOAD=50), приоритета сервиса (PRIO=60) и параметр маршрутизации — имя поля в буфере запроса, по значению которого производится маршрутизация (ACCOUNT_ID).

Сами же параметры маршрутизации запроса описываются в секции *ROUTING, где для каждого параметра указывается поле буфера и тип буфера (FML — это тип буфера, который будет описан в Разд. Обмен данными между клиентом и сервером), а также — диапазон значений поля и группа серверов, к которой будет направлен запрос (ключевое поле RANGES).

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

Маршрутизация запросов — это один из исключительно полезных механизмов, обеспечивающих эволюционное развитие прикладной системы, вначале реализованной как централизованная, но затем начавшей миграцию к распределенной архитектуре.

Динамическое распределение загрузки

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

Рассмотрим следующую задачу. Пусть имеется Sun SPARCcluster PDB из двух узлов на базе компьютеров SPARCcenter 2000E с СУБД Oracle 7.x (Oracle Parallel Server), который используется в информационной системе в качестве сервера баз данных. В качестве рабочих мест конечных пользователей используются персональные компьютеры под управлением MS-Windows с компонентом Tuxedo System/WS, на которых выполняются программы-клиенты приложения. Они подключаются к узлам кластера и работают с базой данных на кластере посредством направления SQL-запросов.

Необходимо разработать программный механизм рациональной загрузки ОБОИХ узлов кластера, позволяющий динамически перенаправлять SQL-запросы тому или иному узлу в зависимости от его загруженности. То есть, если один из узлов кластера загружен на 90%, а другой - только на 10%, то необходимо выравнять загрузку, перенаправив часть SQL-запросов с первого узла на второй (Рис. 4). Эту задачу программное обеспечение кластера не решает, поэтому ее приходится решать самостоятельно.

Проблема состоит в том, что при использовании традиционной RDA-модели (а именно она имеет место в рассматриваемой задаче) программы-клиенты в начале работы с базой данных явным образом подключаются к одному из узлов кластера и в течение всего сеанса работы направляют SQL-запросы именно ему. Таким образом, схема подключения является необратимо жесткой и для перенаправления запросов с одного узла на другой необходимо предусмотреть анализ загрузки сервера в самой программе-клиенте (что концептуально ошибочно) и автоматическое переключение на другой узел кластера.

Решение задачи может быть следующим. Функции маршрутизации запросов (то есть перенаправления их на тот или иной узел кластера в зависимости от ситуации с их загрузкой) выполняет специальная программа-диспетчер. Продумывается и реализуется (в рамках программы-диспетчера) несколько стратегий распределения запросов между узлами кластера (стратегия выравнивания загрузки).

Разрабатывается программа-монитор, следящая за загрузкой каждого из узлов (Oracle 7.x предоставляет соответствующие средства мониторинга производительности) и оповещающая программу-диспетчер (например, через посылку незатребованных сообщений, см. далее) о превышении уровня допустимой загрузки кластера. Реакцией программы-диспетчера будет перенаправление части запросов (в зависимости от выбранной стратегии выравнивания загрузки) на другой узел кластера. В целях повышения надежности работы системы обе программы (и Tuxedo System/T) функционируют на компьютере-сервере приложения (может быть использован SPARCserver 1000E или SPARCserver 20), который дублируется дополнительным компьютером. То есть имеем основной и резервный сервер приложения; в случае выхода из строя основного сервера приложения программа-диспетчер и программа-монитор мигрируют на резервный компьютер и работа продолжается. Суть решения — вводится промежуточное программное обеспечение, экранирующее от программ-клиентов узлы кластера и берущее на себя функции мониторинга загрузки узлов и маршрутизации запросов. В решении используется модифицированный механизм data routing.

Детальное решение задачи имеется в Jet Infosystems и может быть предоставлено всем интересующимся.

Мультиплексирование запросов к базам данных

Tuxedo System можно рассматривать как своеобразный программный мультиплексор запросов к базам данных. Небольшие затраты на его приобретение с лихвой компенсируются экономией на лицензии на использование СУБД, а возможности самой прикладной системы по наращиванию производительности и достижению оптимальной пропускной способности при этом значительно расширяются.

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

Совершенно иначе выполняется подключение клиентов в системах с трехзвенной архитектурой (Рис. 1). Во-первых, клиент вообще не обращается к базе данных — он ее "не видит" и ничего не подозревает о ее существовании. Клиент обращается с запросами к серверу приложений в одном из режимов, описанных выше. Взаимодействие клиента и сервера приложения контролирует Tuxedo System/T. Подключение к System/T клиента (начало сеанса) выполняется вызовом tpinit(); терминирование связи (завершение сеанса) производится вызовом tpterm().

Подключение к СУБД выполняется сервером приложений, а взаимодействие с базой данных (выборка, обновление) производится в рамках сервисов. Схема работы выглядит следующим образом. Клиент приложения подключается к Tuxedo System/T, формирует исходные данные в буфере и вызывает сервис, передавая ему данные. Сервис, в свою очередь, извлекает данные из буфера и формирует SQL-запрос, который направляет соответствующему менеджеру ресурсов (СУБД). Получив от него в ответ данные, сервис размещает их в результирующем буфере и направляет его клиенту. Клиент после этого не обязан сохранять подключение — он может завершить сеанс работы, отключившись от System/T и дав возможность подключиться к System/T другому клиенту. Главное заключается в том, что единственные исполнители прикладных действий — сервисы — не монополизированы каким-либо клиентом, а доступны для общего использования всеми клиентами. Скорость обработки запросов клиентов к сервисам определяется скоростью обработки System/T очередей запросов; увеличить ее можно при помощи механизмов приоритетов и баланса загрузки, а также увеличением числа копий процессов, предоставляющих данный сервис (то есть можно свободно наращивать пропускную способность системы).

Таким образом, для систем с трехзвенной архитектурой, работающих под управлением Tuxedo, не существует ограничений на количество клиентов. Это и является причиной, объясняющей применение менеджеров транзакций (и Tuxedo в том числе) для систем, характеризуемых сверхбольшим числом клиентов.

Во-вторых, в системах с трехзвенной архитектурой резко сокращается число одновременных подключений к СУБД (что существенно уменьшает стоимость лицензии на ее использование). Как мы видим, клиенты к СУБД не подключаются. Подключение к СУБД производится процессом- сервером приложения (от каждого процесса по одному подключению). Каждый такой процесс обрабатывает запросы, поступающие от множества клиентов. Следовательно, количество подключений к СУБД определяется общим числом серверов в приложении, и никак не зависит от количества клиентов. Фактические данные, приведенные, например, в [5], свидетельствуют о том, что количество подключений к СУБД в системах с трехзвенной архитектурой по сравнению с традиционной технологией применения СУБД может быть уменьшено минимум в 4, максимум — в 16 раз, а выигрыш в стоимости в приобретении пары "менеджер транзакций — СУБД" по сравнению с приобретением только СУБД (как это ни кажется парадоксальным) может достигать 50%.

Архитектура приложения

Как мы уже указывали выше (Разд. Основные понятия), приложение в терминологии Tuxedo System представлено коллекцией серверов приложений, предоставляющих осмысленный с точки зрения прикладной области набор услуг, и клиентов приложений, которые за этими услугами обращаются. Серверы приложений объединяются в группы по различным признакам (например, серверы приложений, запускаемые на одном компьютере, объединяются в группу, как это показано в Листинг 1).

Приложение имеет набор параметров (имена и описания серверов и сервисов, имена и описания компьютеров, параметры сети, показатели баланса загрузки, описания менеджеров ресурсов, к которым обращается приложение и т.д). Упорядоченный набор параметров приложения, каждому из которых поставлено в соответствие его значение, называется описанием приложения. Последнее разбито на секции. В них определены: узлы (компьютеры), по которым распределено приложение; группы процессов (серверов); сами серверы; сервисы, доступные в приложении; менеджеры ресурсов, с которыми работает приложение; различные аспекты маршрутизации запросов; данные о приоритетах сервисов; данные для балансирования загрузки и некоторые другие данные. Вся информация об архитектуре приложения вынесена из кодов и сконцентрирована в его описании. Это — важнейший принцип Tuxedo System, позволяющий настраивать приложение, не затрагивая его кодов. Приведем в качестве примера (Листинг 2) описание простейшего приложения, предоставляющего два сервиса - REPORT и PRINT (пример клиента этого приложения будет рассмотрен в Листинг 9).

Над приложением определены две основные операции: старт (выполняется утилитой tmboot()) и останов (выполняется утилитой tmshutdown()). Выполняет эти операции администратор приложения - человек, отвечающий за нормальное функционирование приложения, устанавливающий и изменяющий его параметры.

Старт приложения происходит следующим образом. System/T запрашивает у операционной системы необходимые приложению ресурсы межпроцессного взаимодействия; загружает параметры приложения из файла с описанием приложения в разделяемую память; размещает в разделяемой памяти служебные структуры, необходимые для работы приложения; запускает служебные процессы System/T; запускает серверы приложения. Сегмент разделяемой памяти, где System/T размещает служебные структуры и параметры приложения, носит несколько странно звучащее в данном контексте название "доска объявлений" (Bulletin Board). В частности, System/T выставляет на доску объявлений имена доступных в приложении сервисов. "Доска объявлений" обслуживается служебным процессом System/T под названием BBL (Bulletin Board Language).

Успешное завершение tmboot() означает, что приложение стартовало и готово к работе, и для клиентов приложения доступны его сервисы. Отметим как важнейшую особенность, что клиенты адресуют в своих запросах только сервисы, не указывая серверы, эти сервисы содержащие. Внутреннее устройство приложения невидимо клиентам; более того, им невидимо и расположение приложения — на каком из узлов сети оно выполняется; более того, им совершенно ничего не известно об используемых приложением менеджерах ресурсов. Следовательно, можно считать, что между клиентами и сервисами System/T образует информационную шину; клиенты направляют в нее запросы, адресуя в них конкретный сервис; функции маршрутизации запросов, коммуникации клиента и сервера, управления транзакциями выполняет Tuxedo System/T (Рис. 1).

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

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

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

Обмен данными между клиентом и сервером

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

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

В Tuxedo System разработан специальный механизм структуризации данных. Речь идет о структурированных (fielded) или типизированных (typed) буферах.

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

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

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

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

Вообще говоря, описания FML-буфера в текстовом файле достаточно для того, чтобы клиент и сервер обращались к соответствующему FML-буферу и размещали в нем данные и выбирали их из него. Для этого только должны быть определены две переменные окружения — FLDTBLDIR (имя каталога, где лежит файл с описанием FML-буфера) и FILETBLS (имя самого файла).

Если же мы хотим иметь описания полей непосредственно в тексте программы-клиента или программы-сервера, мы можем воспользоваться утилитой mkfldhdr(), которая конвертирует описание буфера в файл <имя файла описания буфера>.h. Полученный файл содержит для каждого поля буфера следующую строку:

#define fname fieldid

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

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

Отметим, что для FML-буфера его размер вычисляется особым образом; далее в примерах при передаче FML-буфера от клиента к сервису, параметр "размер буфера" устанавливается равным нулю, хотя на самом деле размер буфера, конечно, нулю не равен.

Программист может разработать собственные типы буферов и использовать их в программах. По сути, FML предлагает программисту набор собственных типов данных Tuxedo System и возможности для его расширения.

Важно, что Tuxedo System обеспечивает преобразование данных при передаче их между компьютерами, имеющими различия в архитектурных решениях. Так, данные целого типа, размещенные в FML-буфере на компьютере на базе процессоров Intel 386/486, будут переданы на SPARC-компьютер и восприняты как данные типа int соответствующей разрядности. Различия в типах и разрядности процессоров и другие архитектурные различия фиксируются в параметрах приложения в секции *MACHINES. Установив различия в значениях соответствующих параметров, T&CM (вот, кстати, почему он не только менеджер транзакций, но и коммуникаций) вызывает программу преобразования форматов данных и только после этого передает данные адресату. Если различий нет, то преобразования не производятся.

Tuxedo ATMI

Для организации взаимодействия клиента и сервера используется интерфейс прикладного программирования Tuxedo ATMI (функции ATMI перечислены в Таб. 1).

Как мы видим, Tuxedo ATMI исключительно прост и обозрим - всего 34 функции.

Кратко поясним группы вызовов. Интерфейс приложения включает две функции — tpinit() и tpterm(), которые будут описаны ниже. Интерфейс управления буферами обеспечивает основные операции с типизированными буферами (отметим, что операции над FML-буферами выделены в особую библиотеку и не включены в Tuxedo ATMI).

Одна из особенностей Tuxedo — возможность организации взаимодействия клиента и сервера в одном из нескольких режимов: синхронном, асинхронном, диалоговом, с хранимыми очередями. Возможны также модификации режимов; кроме того, клиент и(или) сервер может рассылать сообщения клиентам в асинхронном режиме. Большое число режимов позволяет разработчику выбрать оптимальный для конкретной задачи способ взаимодействия и реализовать его с помощью функций ATMI.

Интерфейс незатребованных (unsolicited) сообщений требует особых комментариев. В Tuxedo можно предусмотреть рассылку сообщений от клиентов и (или) серверов приложений клиентам (то есть инициатором сообщения может быть и клиент, и сервер, а вот получателем — только клиент).

Сообщения передаются в типизированных буферах и называются незатребованными - получатель реагирует на них асинхронно. Можно организовать рассылку сообщений по именам клиентов либо широковещательную рассылку всем клиентам приложения (вызов tpbroadcast()). Если необходимо послать (от сервера) сообщение конкретному клиенту (адресуя его по идентификатору клиента), следует воспользоваться вызовом tpnotify().

Рассылка сообщений — отличный прием для уведомления клиентов о всех событиях, происходящих в приложении, в том числе о событиях, происходящих в базе данных. Клиент реагирует на получение сообщения, передавая управление функции обработки сообщений, адрес которой был предварительно указан с помощью вызова tpsetunsol(). Клиент может также периодически опрашивать свою очередь сообщений при помощи вызова tpchkunsol(). Способ реакции на сообщения напрямую зависит от операционной среды, в которой выполняется клиент, и устанавливается значением одного из полей буфера инициализации приложения.

Интерфейс управления транзакциями включает функции, определяющие начало (вызов tpbegin()) и успешное завершение (tpcommit()) транзакции — как локальной, так и распределенной (напомним, что транзакции в понимании Tuxedo — это обычные ACID-транзакции. Они характеризуются четырьмя классическими свойствами — атомарности, согласованности, изолированности, долговечности — Atomicity, Consistensy, Isolation, Durability (ACID). Свойство атомарности выражается в том, что транзакция должна быть выполнена полностью или не выполнена вовсе. Свойство согласованности гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - транзакция не нарушает взаимной согласованности данных. Свойство изолированности означает, что конкурирующие за доступ к данным транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно. Наконец, свойство долговечности трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах.

Функция tpabort() откатывает изменения, выполненные в рамках текущей транзакции всеми задействованными транзакцией XA-совместимыми менеджерами ресурсов (например, SQL-серверами).

Интерфейс динамического объявления сервисов позволяет в процессе работы приложения объявлять (делать доступными для клиента) дополнительные сервисы и связывать их с конкретными функциями (в терминах языка C). Дело в том, что каждому приложению, как мы знаем, приписан некоторый вполне определенных набор сервисов, имена которых заданы в параметрах приложения (секция *SERVICES в Листинг 2), а исполняемый код функций, ассоциированных с сервисами, содержится в серверах. Таким образом, изначально, после старта приложения, мы имеем статичный набор сервисов, причем информация о каждом сервисе (имя сервиса, адрес функции, ему приписанной и т.д.) содержится в строке таблицы сервисов, расположенной на доске объявлений. Функция tpadvertise() добавляет новую строку в эту таблицу, то есть динамически изменяет список сервисов приложения, выставляя новый сервис на доску объявлений и приписывая ему конкретную C-функцию, после чего сервис становится доступным для вызова. Функция tpunadvertise() удаляет запись о сервисе из таблицы сервисов, делая обращение к нему невозможным.

Tuxedo System/Q — это специализированный менеджер ресурсов в составе Tuxedo System, управляющий хранимыми на диске очередями запросов. Помещение в очереди и выборка из них — прерогатива служебных процессов, которые запрашивают менеджер очередей для выполнения соответствующих действий.

Клиент адресует запрос конкретному сервису. Для каждого из сервисов на диске строятся собственные очередь запросов и очередь ответов. Помещением сообщений в первую очередь и извлечением их из второй ведает сервер TMQUEUE. Сервер TMQFORWARD выбирает сообщения из очереди запросов и помещает сообщения в очередь ответов.

Упрощенно работа с очередями выглядит следующим образом (Рис. 6). Клиент посылает запрос сервису, а System/T направляет его серверу TMQUEUE (вызов tpenqueue()). Последний помещает сообщение в очередь запросов к данному сервису. Сервер TMQFORWARD извлекает сообщение из очереди запросов и направляет его сервису (вызов tpcall()). Последний, выполнив предписанные действия и сформировав ответ на запрос также в виде сообщения, посылает его в очередь ответов. Клиент, при помощи вызова tpdequeue(), запрашивает сервер TMQUEUE на предмет получения сообщения из очереди ответов, что тот и выполняет.

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

Клиент и сервер приложения

Клиент и сервер как программы на языке C имеют специфическую структуру, которая будет описана ниже.

Логика функционирования клиента приложения такова. Клиент должен инициировать связь с Tuxedo System/T, передав ему сведения о себе, выделить динамическую память под исходный и результирующий буфера данных. Затем клиент может обращаться к серверу различными способами, которые будут описаны ниже. Завершив взаимодействие с сервером, клиент должен освободить память, выделенную под буфера, и терминировать связь с System/T. Логика клиента описана в псевдокодах в Листинг 5.

Клиент и сервер приложения

Клиент и сервер как программы на языке C имеют специфическую структуру, которая будет описана ниже.

Логика функционирования клиента приложения такова. Клиент должен инициировать связь с Tuxedo System/T, передав ему сведения о себе, выделить динамическую память под исходный и результирующий буфера данных. Затем клиент может обращаться к серверу различными способами, которые будут описаны ниже. Завершив взаимодействие с сервером, клиент должен освободить память, выделенную под буфера, и терминировать связь с System/T. Логика клиента описана в псевдокодах в Листинг 5.

Буфер инициализации (тип TPINIT) определен в atmi.h и содержит информацию о программе-клиенте: имя пользователя, запускающего программу, имя программы, имя группы программ, флаг, определяющий системные характеристики взаимодействия данного клиента с System/T, а также пароль клиента, который после передачи буфера System/T будет сверен с эталоном пароля из Конфигурационного файла приложения. Таким образом, в начале сеанса работы клиент должен сформировать данные в буфере, запросив их, например, у пользователя, и инициировать связь с System/T посредством вызова tpinit(). Фрагмент программы, выполняющей эти действия, представлен в Листинг 6. В последующих примерах, дабы не перегружать их излишними подробностями, будем использовать этот фрагмент под названием "подключить клиента к System/T".

Отметим, что, как только клиент издал вызова tpinit(), System/T добавляет единицу к общему числу подключенных клиентов. В данном контексте пользователь — это процесс, подключившийся к System/T посредством вызова tpinit().

Отключение клиента от System/T (терминирование связи с System/T) выполняется вызовом tpterm(). Как только клиент использовал этот вызов и он завершился успешно, System/T уменьшает число подключенных клиентов на единицу. Фрагмент "терминировать связь клиента с System/T" представлен в Листинг 7.

Сервер устроен более сложно, нежели клиент. Дело в том, что сервер должен обслуживать запросы нескольких клиентов. Запросы помещаются в очередь запросов к серверу, которая обслуживается Tuxedo System/T. Очередь запросов организована по приоритетному принципу. System/T извлекает запрос из очереди и передает его тому сервису сервера, которому он был адресован (имя адресуемого сервиса присутствует в структуре запроса).

Перед тем как начать извлечение запросов из очереди, System/T объявляет все сервисы, которые доступны в данном сервере. Для этого System/T обращается к параметрам приложения, размещенным после загрузки из конфигурационного файла в разделяемой памяти и выставляет на доску объявлений имена сервисов данного сервера.

Сервисы имеют приоритеты — целые положительные числа в диапазоне от 1 до 100. Приоритет определяет порядок извлечения запроса из очереди (первыми обрабатываются запросы к сервисам, имеющим наивысший приоритет). Начальные значения приоритетов сервисов задаются в параметрах приложения в секции сервисов; далее они могут изменяться динамически либо посредством использования MIB, либо при помощи вызова tpsprio(). Интуитивно ясно, что этот вызов может использоваться, если следующий запрос должен быть выполнен немедленно — и с этой целью устанавливается максимальный приоритет адресуемого в запросе сервиса (после выполнения запроса приоритет сервиса можно вернуть в исходное значение — разумеется, оно должно быть предварительно получено функцией tpgprio()). Приоритетность обслуживания запросов в очереди к серверу отнюдь не означает, что запросы к сервисам с низкими приоритетами будут бесконечно долго находиться в ней - через некоторый промежуток времени System/T выполняет ревизию очереди, направляя на обработку сервисам "засидевшиеся" в очереди процессы. Кажется несколько странным, что приоритеты имеются у сервисов, а не у запросов, как это должно быть по логике вещей. На самом деле приоритеты все-таки у запросов - просто приоритет запроса в точности равен приоритету сервиса, которому он направлен.

Код сервера состоит из двух частей: прикладной и системной. Прикладная часть, представляющая собой реализацию сервисов данного сервера (как функций в терминологии языка C), пишется разработчиком приложения. Системная часть сервера (main-компонент) добавляется Tuxedo System/T на этапе препроцессирования исходного кода сервера. Логика сервера приложения представлена в Листинг 8.

Расширенная модель "клиент-сервер"

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

Синхронный режим

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

Передача запроса выполняется функцией Tuxedo ATMI tpcall(). Ниже (Листинг 9) приведен простейший пример использования синхронного режима. Клиент запрашивает сервис "REPORT", получает запрошенный отчет в буфере rbuf и передает его сервису "PRINT", который выполняет печать отчета. Вызов сервиса в синхронном режиме сходен с механизмом RPC (вызов удаленных процедур).

 Вызов tpcall() определен следующим образом:

int tpcall (svc, ibuf, ilen, obuf, olen, flags)

char *svc, *ibuf, **obuf;

long ilen, *olen, flag;

Здесь svc — имя запрашиваемого сервиса; сам сервис должен быть описан в приложении, а его имя выставлено на доску объявлений приложения; *ibuf — исходный буфер, ilen — его размер; **obuf — результирующий буфер, *olen — его размер; flag — устанавливает дополнительные параметры взаимодействия клиента и сервера и обработки транзакций, по умолчанию должен быть установлен в 0.

Обратим внимание — фрагмент программы, названный в данном примере и всех примерах следующих ниже "Обработка ошибки", на самом деле означает выполнение следующих действий:

• Вызвать функцию обработки ошибок;
• Освободить память, выделенную под буфера;
• Терминировать связь с System/T;
• Завершить программу.

Асинхронный режим

Более естественным и менее жестким является асинхронный режим. Так же, как и в синхронном режиме, клиент запрашивает необходимый ему cервис (посредством вызова функции tpacall()), передавая ему данные в буфере, однако он не ожидает ответа, но продолжает выполнять действия, определенные в программе. Ответ на запрос клиент получает с помощью вызова tpgetreply(). Таким образом, клиент и cервер работают асинхронно. Вызов tpacall() определен следующим образом:

int tpacall (svc, ibuf, ilen, flags)

char *svc, *ibuf;

long ilen, flags;

Смысл параметров тот же, что и для вызова tpcall(). Отметим, что среди параметров отсутствуют результирующий буфер и его размер. Вызов tpacall() возвращает целое значение, которое затем используется как дескриптор вызова в функции tpgetreply(). Ее синтаксис выглядит следующим образом:

int tpgetreply (cd, obuf, olen, flags)

int *cd;

char **obuf;

long *olen, flags;

где cd — это дескриптор вызова, полученный как результат предшествующего вызова tpacall(), а остальные параметры означают то же самое, что и для функции tpcall().

Используя функцию tpgetreply(), клиент ожидает (некоторое время или бесконечно долго — в зависимости от того, каково значение или комбинация значений параметра flags) ответа от cервиса, который был вызван одним из предшествующих вызовов tpacall(). Если для вызова tpgetreply() был установлен некоторый тайм-аут, и по его прошествии клиент не получает ответа, tpgetreply() возвращает ошибку.

Диалоговый режим

В диалоговом (conversational) режиме System/T открывает канал для взаимодействия между клиентом и cервисом. Канал функционирует в полудуплексном режиме. Клиент и cервис могут посылать запросы в канал, но не одновременно. В каждый конкретный момент времени контроль над каналом принадлежит либо клиенту, либо cервису. Тот, кто имеет контроль над каналом (инициатор), направляет в него запросы, которые получает противная сторона (субординатор). Инициатор может вместе с запросом передать и контроль над каналом субординатору — тогда они меняются ролями. Открыть и закрыть канал может только клиент. Диалог продолжается до тех пор, пока инициатор не закроет канал, либо не произойдет ошибка и System/T не закроет канал самостоятельно. Сервер, реализованный специально для взаимодействия с клиентами в диалоговым режиме, будем называть диалоговым сервером.

Диалоговый режим взаимодействия обеспечивается следующими вызовами: tpconnect() — открыть канал, tpsend() — передать данные, tprecv() — получить данные, tpdiscon() — закрыть канал. Их детали разъясняются ниже.

int tpconnect (name, data, len, flags)

char *name, *data;

long len, flags;

Здесь name — имя сервиса, выставленное на доску объявлений диалоговым сервером, data — указатель буфера с передаваемыми данными (во время установления связи можно передать данные сервису), len — размер буфера, flags — флаги. Вызов tpconnect() возвращает целое число — дескриптор открытого канала, по которому и производятся дальнейшие запись в канал и чтение из него.

int tpsend (cd, data, len, flags, revent)

int cd;

char *data;

long len;

long flags;

long *revent;

Здесь cd — дескриптор канала, data — указатель буфера данных, len — размер буфера, flags — флаги, revent — значение "события", инициированного вызовом tpsend() (что называется событием, будет разъяснено ниже). Значения флагов такие же, как и для вызова tpcall(), плюс еще два значения: TPSENDONLY - контроль над каналом остается у инициатора соединения (как в примере, приведенном ниже); TPRECVONLY — контроль над каналом и инициатива передачи данных передается субординатору.

int tprecv (cd, data, len, flags, revent)

int cd;

char **data;

long *len;

long flags;

long *revent;

Здесь смысл параметров тот же, что и для вызова tpsend(). Параметр revent необходим для уведомления процесса-собеседника о дальнейших действиях. Так, в приведенном ниже примере в результате вызова tprecv() переменная revent может получить значение TPEV_SVCSUCC, что означает, что субординатор (в нашем случае — сервис "DIALOG" — успешно завершил свою работу). Реакцией на это инициатора (клиента) является завершение диалога.

Диалоговый режим необходим в тех случаях, когда клиенту срочно потребовалось "побеседовать" с конкретным сервисом таким образом, чтобы никакие другие клиенты не могли их прервать в этой беседе. Клиент захватывает на монопольное использование сервис и в течение всего сеанса диалога (от открытия канала до его закрытия) никакие другие клиенты не могут запрашивать данный сервис. В качестве примера (Листинг 10)приведем простейший случай диалогового взаимодействия.

Рассылка сообщений

Выше уже говорилось о возможности рассылки так называемых незатребованных сообщений. Рассмотрим пример широковещательной рассылки, которая инициируется клиентом и направляется всем подключенным к System/T клиентам приложения. Рассылается текстовое сообщение (помещенное в буфер типа STRING), получаемое из командной строки при запуске клиента. В Листинг 11 приведен пример инициатора и получателя сообщений (оба — клиенты приложения). Операция выполняется функцией tpbroadcast(), имеющей следующий синтаксис:

int broadcast (lmid, usrname, cltname, data, len, flags)

char *lmid, *usrname, *cltname, *data;

long len, flags;

Здесь lmid — идентификатор узла, usrname и cltname - опознавательные знаки клиента-получателя сообщения. Использование NULL для всех трех аргументов означает рассылку сообщения всем клиентам, подключенным к System/T. Сообщение пересылается в буфере, указатель на который есть data, а len - размер буфера (для FML-буферов len равно 0).

Управление транзакциями

Tuxedo System полностью удовлетворяет стандарту обработки распределенных транзакций консорциума X/Open (X/Open DTP - Distributed Transaction Processing). Модель X/Open DTP (Рис. 7) описывает взаимодействие трех субъектов обработки транзакций — прикладной программы (в качестве прикладной программы фигурирует как клиент, так и сервер приложения), менеджера транзакций (в нашем случае это - System/T) и менеджера ресурсов, конкретно — СУБД. Роль менеджера транзакций в модели X/Open DTP — роль диспетчера, главного координатора транзакций. Он обладает полным набором управления как локальными, так и глобальными, распределенными транзакциями. В последнем случае транзакция может обновлять данные на нескольких узлах, причем управление данными на них осуществляется различными СУБД. Обработка распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации транзакций, который гарантирует целостность данных в информационной системе, распределенной по нескольким узлам, независимо от того, какая СУБД управляет обработкой данных на каждом таком узле.

Понятие транзакции в Tuxedo System и в традиционных СУБД отличаются. Суть остается одной ("все или ничего"), но в понимании СУБД транзакция — это атомарное действие над базой данных, в то время как в Tuxedo System транзакция трактуется гораздо шире. Она включает не только операции над базой данных, но и любые другие действия — передачу сообщений, запись в индексированные файлы, опрос датчиков и т.д. Не нужно понимать это утверждение буквально (так, разумеется, невозможно вернуть назад отправленное сообщение, но, однако, в случае отката транзакции можно отправить вслед сообщению уведомление о его отмене). При этом вовсе не обязательно, чтобы все менеджеры ресурсов, затронутые в рамках выполнения транзакции, поддерживали бы XA-интерфейс. Да было бы странно это требовать, поскольку в круг XA-совместимых менеджеров ресурсов входят только СУБД (да и то не все), и некоторые менеджеры файловых систем. Использование только XA-совместимых менеджеров ресурсов позволяет добиться синхронной фиксации изменений в соответствующих ресурсах или синхронного же их отката. При этом вполне допустимо использование специализированных менеджеров ресурсов, не имеющих XA-интерфейса (но тогда не гарантирована синхронизация изменений и о ней программист должен позаботиться сам). Наконец, в качестве менеджеров ресурсов можно рассматривать и применять в трехзвенной схеме очень многое — например, системы опроса и управления датчиками (но в этом случае разработчик должен самостоятельно продумать и реализовать принципы управления этим RM). Все это позволяет реализовать при помощи Tuxedo System прикладные транзакции (бизнес-транзакции), что в СУБД, вообще говоря, сделать невозможно.

Вначале рассмотрим, как происходит взаимодействие сервера приложения с СУБД. Приложение может обращаться к нескольким СУБД. Взаимодействие может осуществляться в двух режимах. В первом, простейшем режиме, управление транзакциями берет на себя сама СУБД — тогда для указания границ транзакции используются SQL-операторы конкретной СУБД (BEGIN TRANSACTION, COMMIT TRANSACTION, ROLLBACK TRANSACTION). Tuxedo System не принимает никакого участия в обработке такой транзакции. Ясно также, что в этом режиме можно задать распределенную транзакцию, но только в однородной среде (на узлах, затрагиваемых транзакцией, обработку данных выполняет одна и та же СУБД, например, Oracle). Для нас этот случай неинтересен, поскольку Tuxedo System используется не в полную меру и фактически устраняется от управления транзакциями.

В другом режиме управление транзакциями берет на себя Tuxedo System. Любая СУБД, с которой взаимодействует прикладная программа, рассматривается как RM. Для того, чтобы можно было работать с СУБД в этом режиме, необходимо, чтобы это была СУБД, удовлетворяющая стандарту X/Open XA. В настоящий момент этому стандарту соответствуют Informix-OnLine Dynamic Server, Sybase, CA-OpenIngres, Oracle. В самое последнее время к этому списку присоединился Microsoft SQL Server.

Стандарт XA описывает небольшой набор вызовов, предоставляющий интерфейс к данной СУБД для менеджеров Транзакций, а сам XA-интерфейс есть библиотека функций, поставляемая либо непосредственно с сервером конкретной СУБД (например, с Oracle), либо с компонентом ESQL/C (так сделано в Informix), либо как отдельный компонент (CA-OpenIngres DTP).

В любом случае сервер приложения обращается к СУБД путем использования одного из диалектов ESQL/C. Ниже (Листинг 12) для иллюстрации приводится текст сервиса "Подсчет баланса" (BALANCE). Пример приведен для того, чтобы читатель понял, что обращения к базе данных производятся внутри конкретного сервиса, реализованного в сервере приложения (клиент вообще ничего не знает о существовании базы данных), и описывается это обращение на так называемом "встроенном" (embedded) SQL. Никаких предписаний управления транзакциями в примере нет, так как с их помощью определяются не транзакции по работе с базами данных, а прикладные транзакции (в которых подсчет баланса является составляющим действием) и определяются они, как правило, в клиенте приложения. В примере сервис обращается к СУБД Informix.

Сервис получает от клиента сообщение в VIEW-буфере, извлекает из него номер филиала, обращается к СУБД с запросом на подсчет баланса для данного филиала, помещает результат в буфер и возвращает его клиенту.

Пример иллюстрирует фундаментальное различие между технологией "SQL-клиент — SQL-сервер" и технологией менеджеров транзакций. В первом случае клиент явным образом запрашивает данные, зная структуру базы данных (это называется поставкой данных — data shipping). Клиент передает SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка-точка", для реализации которой все СУБД используют закрытый SQL-канал. Он строится двумя процессами: SQL/Net на компьютере-клиенте и SQL/Net на компьютере-сервере и порождается по инициативе клиента оператором CONNECT.

В случае трехзвенной схемы клиент явно запрашивает сервис, передавая ему в буфере сообщение и получает ответ также в буфере. Клиент направляет запрос в информационную шину (которую строит System/T), ничего не зная о месте расположения сервиса. Это называется поставкой функций — function shipping. Важно, что для клиента база данных закрыта слоем сервисов. Более того, он вообще ничего не знает о ее существовании, так как все операции над базой данных выполняются внутри сервисов.

Для управления транзакциями используются вызовы tpbegin(), tpcommit(), tpabort(). Начало транзакции отмечается вызовом tpbegin(). Получив его, System/T добавляет в таблицы транзакций информацию о данной транзакции, и связывает с ней все дальнейшие действия (действия после tpbegin()), инициируемые прикладной программой. То есть, любые операции над базой данных, предпринятые после вызова tpbegin(), осуществляются в рамках данной транзакции (одной из многих, одновременно контролируемых System/T). Транзакция может завершиться одним из двух способов.

Использование tpcommit() влечет за собой фиксацию всех изменений, достигнутых в рамках текущей транзакции — то есть изменений в базе данных, полученных в результате выполнения операторов SQL, которые следовали после tpbegin(). Анатомия tpcommit() такова. Функция tpcommit() обращается к System/T. System/T издает вызов XA-функции, ответственной за фиксацию транзакций — таким образом, System/T заставляет СУБД зафиксировать транзакцию, после чего удаляет информацию о данной транзакции из своих внутренних таблиц. Напротив, вызов tpabort() приводит к откату всех изменений, сделанных в рамках текущей транзакции. Таким образом, если транзакция — локальная, то вызовы tpbegin(), tpcommit(), tpabort() попросту заменяют соответствующие операторы SQL BEGIN TRANSACTION, COMMIT TRANSACTION, ROLLBACK TRANSACTION или их аналоги.

На самом деле функция tpcommit() устроена несколько сложнее. Дело в том, что вызов tpcommit() инициирует двухфазный протокол фиксации текущей транзакции. Первая фаза состоит в том, что все RM (читай — СУБД) опрашиваются о готовности зафиксировать транзакцию (изменения в базы данных уже внесены, но еще не зафиксированы). Получив от всех RM отклик о готовности, System/T инициирует фиксацию, направляя всем им соответствующую команду через XA-интерфейс. Если в момент выполнения первой фазы кто-либо из RM не откликнулся, System/T повторяет опрос, и в случае неудачи направляет RM команду на откат изменений.

System/T ведет собственный журнал транзакций, куда отображает всю информацию о транзакциях, находящуюся в ее собственных таблицах. Транзакционные таблицы, кстати, размещаются на доске объявлений. После любого сбоя, разрушившего внутренние структуры System/T (или вообще приведшего к очистке оперативной памяти компьютера) при загрузке приложения вся информация о транзакциях восстанавливается на доске объявлений из журнала транзакций, и, используя ее, System/T откатывает все незавершенные на момент сбоя транзакции.

Общая схема управления распределенными транзакциями выглядит следующим образом. Во-первых, разработчик приложения указывает в параметрах приложения в секции *GROUPS менеджеры ресурсов, которые будут принимать участие в транзакции. Для этого используется параметр OPENINFO. В строке OPENINFO указывается информация, необходимая для инициации RM: тип менеджера ресурсов, расположение и имя базы данных, режим работы с базой данных — только чтение или чтение и запись. Связь между System/T и RM обеспечивает так называемый сервер управления транзакциями (Transaction Management Server — TMS). Имя TMS указывается параметром TMSNAME секции *GROUPS, а само имя совпадает с именем файла, который порождается утилитой buildtms(). В момент загрузки приложения в числе прочих запускается процесс TMS, который и инициирует подключение приложения к RM, для которого этот TMS был построен. Для каждого RM запускается свой TMS, который и управляет транзакциями, направляемыми к данному менеджеру ресурсов.

Обычно транзакция определяется в клиенте приложения и содержит вызов нескольких сервисов, которые и обращаются к базе данных. Схема определения распределенной транзакции представлена на Листинг 13. При этом сервис SRV1 содержит Informix-ESQL/C-операторы, в то время как операции с данными сервиса SRV2 определены как операторы Oracle Pro*C.

Заключение

Мы описали лишь небольшую часть возможностей Tuxedo System. Как мы видим, изложенные идеи и подходы настолько интересны, что выходят за рамки конкретного продукта и представляют собой особый метод разработки информационных систем. Jet Infosystems позиционирует его как альтернативный традиционной технологии "SQL-клиент-SQL-сервер", и во многих случаях более сильный.

Литература

1. Г.М Ладыженский -- Система обработки распределенных транзакций Tuxedo -- Открытые Системы, весна 1993 года
2. Г.М Ладыженский -- Технология "клиент-сервер" и мониторы транзакций -- Открытые Системы, лето 1994 года
3. Олег Москаленко -- Применение технологии "клиент-сервер" в банке АКБ "РПБ" -- Jet Info, 6
4. Сергей Севрюгин -- Система обработки финансовых сообщений -- Jet Info, 6
5. The Standish -- Client-Server Goes Business Critical. Transaction Processing Monitors. Key to Next Generation of Applications

I. Технические характеристики Tuxedo System 6.1

Основные возможности .

• Синхронный, асинхронный и диалоговый режимы взаимодействия "клиент-сервер"
• Широковещательная рассылка сообщений
• Подсистема очередей сообщений с гарантированной доставкой
• Подсистема управления транзакциями
• Задаваемый программистом механизм идентификации клиентов и авторизации доступа к приложению
• Разработка на языках программирования C, C++, COBOL
• Средства трассировки вызовов Tuxedo ATMI
• Статический и динамический баланс загрузки
• Оптимизация пропускной способности системы
• Динамическая маршрутизация запросов
• Матричная масштабируемость
• Автоматическая миграция серверов приложений
• Интеграция с реляционными СУБД CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase
• Протокол двухфазной фиксации транзакций
• Шлюз в IBM CICS, IMS
• Поддержка SNA LU6.2
• Четыре уровня безопасности, включая Kerberos
• Механизм управления событиями по схеме "публикация-подписка" (Event Broker/Monitor)
• Механизм авторизации доступа — списки управления доступом
• Динамическая реконфигурация приложения
• Глобальное управление распределенным приложением
• Программный интерфейс администратора (API)
• Оконный графический интерфейс (OSF/Motif) администрирования
• Централизованное администрирование OLTP-приложений
• База информационного управления приложением (MIB)

Поддерживаемые стандарты .

• X/Open TX
• X/Open XATMI
• X/Open TxRPC
• X/Open XA
• X/Open XATMI ASE
• X/Open RTI ASE
• ISO-TP

Компоненты Tuxedo System 6.x .

• Tuxedo System/T - ядро системы, менеджер транзакций
• Tuxedo System/WS — расширение системы для компьютеров-клиентов
• Tuxedo System/Q — специализированный менеджер очередей сообщений
• Tuxedo System/Host — шлюз в IBM CICS
• Tuxedo System/Domain — централизованное управление доменом узлов Tuxedo
• Tuxedo System/DCE — интеграция Tuxedo - Distributed Computing Environment
• Tuxedo System/Admin — программный интерфейс администрирования приложения

Tuxedo — поддерживаемые платформы .

• Amdahl
• AT&T
• Bull
• Compaq
• Data General
• Dell
• DEC
• Fujitsu
• Hewlett-Packard
• IBM
• ICL
• Intel x86/Pentium
• KSR
• Motorola
• NCR
• NEC
• Oki
• Olivetti
• Pyramid
• Sequent
• Siemens Nixdorf
• Silicon Graphics
• Stratus
• Sun Microsystems
• Tandem Guardian
• Tandem Integrity
• Teradata
• Unisys

Tuxedo (клиент и сервер) — операционные системы и аппаратные платформы .

• AIX 3.2 (IBM RS/6000)
• Dynix (Sequent)
• HP-UX 9.x (HP 9000/800)
• NCR UNIX SVR4 (System 3000)
• Novell NetWare (Intel)
• OSF/1 V3.0 (DEC Alpha)
• Pyramid DataCenter/OSx (MIServer S)
• SCO Open Server 3.x (Intel)
• SunOS 4.1.3 (Sun SPARC)
• Solaris 2.x (Sun SPARC)
• UnixWare 2.x (Intel)
• Ultrix (DEC)
• VMS (DEC)
• Windows NT (Intel)

Tuxedo (только клиент) — операционные системы .

• DOS
• Macintosh
• OS/2 (32 bit)
• Windows (16 bit)
• Windows NT on DEC Alpha (32 bit)
• Windows NT on Intel (32 bit)

Системы, интегрированные с Tuxedo System .

• 4C Quercus
• Ally 4GL
• Borland Delphi
• CA-OpenIngres
• Grasham ISAM
• Gupta SQL Windows
• IBSI Delta
• ICL DMS
• IMC Open/Transport
• Informix-OnLine Dynamic Server
• Informix-NewEra
• iTi iTran
• JACC JAM
• Magna X
• Micro Focus COBOL
• Microsoft SQL Server
• Novell WKSH
• Ochre Development
• Oracle
• PowerBuilder
• Software Associates Change
• Steria CARIATIDES
• SuperNova
• Sybase
• Texas Instruments TI-IEF
• Unify Accell/TP
• Uniface