Более года назад в журнале была опубликована статья о системе TUXEDO [1]. Тема, затронутая в ней, оказалась настолько актуальной, что автор решил вновь вернуться к мониторам транзакций и попытался сделать некоторые обобщения. Хотелось бы, чтобы на статью обратили внимание разработчики и менеджеры современных информационных систем. Тема мониторов транзакций не ограничивается теоретическими аспектами, но имеет непосредственное отношение к практике. Известно несколько проектов, в которых реализованы средства, поразительно напоминающие мониторы транзакций, хотя в ряде случаев разработчики и не подозревали о существовании этого вида программного обеспечения.
Часто программисты, приступающие к проектированию и реализации информационных систем, наталкиваются на ряд проблем и сложностей, происходящих не из их неопытности или недостаточных знаний, но имеющих своей причиной особенности и ограничения, внутренне присущие программным продуктам, имеющих архитектуру "клиент-сервер". Пытаясь решить эти проблемы, они зачастую вынуждены "изобретать велосипед" вместо того, чтобы использовать высокотехнологичные и стандартизованные средства создания распределенных промышленных информационных систем. К таким средствам и относятся мониторы транзакций. Три модели
"Клиент-сервер" - это модель взаимодействия компьютеров в сети. Редко бывает так, чтобы они были совершенно равноправными. Как правило, один компьютер в сети располагает информационно-вычислительными ресурсами, такими как процессоры, файловая система, почтовая служба, служба печати, база данных. Другие же компьютеры пользуются ими. Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса, а компьютер, желающий им воспользоваться - клиентом. Конкретный сервер характеризуется видом ресурса, которым он владеет. Так, если ресурсом являются базы данных, то речь идет о сервере баз данных, назначение которого - обслуживать запросы клиентов, связанные с обработкой баз данных; если ресурс - это файловая система, то говорят о файловом сервере или файл-сервере и т.д.
Этот же принцип распространяется и на взаимодействие процессов. Если один из них выполняет некоторые функции, предоставляя другим соответствующий набор услуг, такой процесс рассматривается в качестве сервера. Процессы, пользующиеся этими услугами, принято называть клиентами.
Сегодня технология "клиент-сервер" получает все большее распространение, однако сама по себе она не предлагает универсальных рецептов. Она лишь дает общее представление о том, как должна быть организована современная распределенная информационная система. В то же время реализации этой технологии в конкретных программных продуктах и даже в видах программного обеспечения различаются весьма существенно.
Один из основных принципов технологии "клиент-сервер" заключается в разделении функций стандартного приложения на три группы, имеющие различную природу. Первая группа - это функция ввода и отображения данных. Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области. Наконец, к третьей группе относятся фундаментальные функции хранения и управления данными (базами данных, файловыми системами и т.д.)
В соответствии с этим в любом приложении выделяются следующие логические компоненты:
- компонент представления (presentation), реализующий функции первой группы;
- прикладной компонент (business application), поддерживающий функции второй группы;
-
компонент доступа к информационным ресурсам (resource acces) или менеджер ресурсов (Resource manager), поддерживающий функции третьей группы.
Различия в реализации приложений в рамках технологии "клиент-сервер" определяются тремя факторами. Во-первых, тем, какие механизмы используются для реализации функций всех трех групп. В-третьих - как логические компоненты распределяются между компьютерами в сети. Выделяются три подхода, каждый из которых реализован в соответствующей модели:
- модель доступа к удаленным данным (Remote Date Access - RDA);
- модель сервера базы данных (DateBase Server - DBS);
-
модель сервера приложений (Application Server - AS).
В RDA-модели коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте, Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (языка SQL, например, если речь идет о базах данных) или вызовами функций специальной библиотеки ( если имеется соответствующий API). Запросы к информационным ресурсам направляются по сети удаленному компьютеру (например, серверу базы данных). Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных (рисунок 1). Говоря об архитектуре "клиент-сервер", в большинстве случаев имеют в виду именно эту модель.
Рис. 1. Модель доступа к удаленным данным
DSB-модель (рисунок 2) строится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции реализованы в хранимых процедурах (stored procedure), которые также называют компилируемыми резидентными процедурами, или процедурами базы данных Они хранятся непосредственно в базе данных и выполняются на компьютере-сервере базы данных (где функционирует и компонент, управляющий доступом к данным, то есть ядро СУБД). Понятие информационного ресурса сужено до баз данных, поскольку механизм хранимых процедур - отличительная характеристика DBS-модели - имеется пока только в СУБД, да и то не во всех.
Рис. 2. Модель сервера базы данных
На практике часто используются смешанные модели, когда поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель). Однако такие решения, включающие элементы сразу двух моделей, не могут принципиально изменить наших представлений о их соотношении.
В AS-модели (рисунок 3) процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за ввод и отображение данных (то есть реализует функции первой группы). Прикладные функции выполняются группой процессов (серверов приложений), функционирующих на удаленном компьютере (или нескольких компьютерах). Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается ровно тем же способом, что и в RDA-модели. Из прикладных компонентов доступны ресурсы различных типов - базы данных, индексированные файлы, очереди и др. Серверы приложений выполняются, как правило, на том же компьютере, где функционирует менеджер ресурсов, однако могут выполняться и на других компьютерах.
Рис. 3. Модель сервера приложений
В чем заключается фундаментальное различие между этими моделями? RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором - интегрируется в компонент доступа к информационным ресурсам. Напротив, в AS-модели реализована классическая трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. Собственно, из этой особенности AS-модели и вытекают ее преимущества, которые имеют важнейшее значение для чисто практической деятельности.
RDA-модель
Главное преимущество RDA-модели лежит в практической плоскости. Сегодня существует множество инструментальных средств, обеспечивающих быстрое создание desktop-приложений, работающих с SQL-ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Иными словами, основное достоинство RDA-модели заключается в унификации и широком выборе средств разработки приложений. Подавляющее большинство этих средств разработки на языках четвертого поколения ( включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления.
RDA-модель имеет ряд ограничений.
Во-первых, взаимодействие клиента и сервера посредством SQL-запросов существенно загружает сеть. Поскольку приложение является нераспределенным и вся его логика локализована на компьютере-клиенте, постольку приложение нуждается в передаче по сети данных большого объема, возможно, избыточных. Как только число клиентов возрастает, сеть превращается в "горлышко бутылки", тормозя быстродействие всей информационной системы.
Во-вторых, удовлетворительное администрирование приложений в RDA-модели практически невозможно. Очевидно, что если различные по своей природе функции (функции представления и чисто прикладные функции) смешаны в одной и той же программе, написанной на языке 4GL, то при необходимости изменения прикладных функций приходится переписывать всю программу целиком. При коллективной работе над проектом, как правило, каждому разработчику поручается реализация отдельных прикладных функций, что делает невозможным контроль за их взаимной непротиворечивостью. Каждому из разработчиков приходится программировать интерфейс с пользователем, что ставит под вопрос единый стиль интерфейса и его целостность.
DBS-модель
Несмотря на широкое распространение, RDA-модель уступает место более технологичной DBS-модели. Последняя реализована в некоторых реляционных СУБД (Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования ядра СУБД. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД. Попытки стандартизации языка SQL, касающиеся хранимых процедур, пока не привели к ощутимому успеху. Кроме того, во многих реализациях процедуры являются интерпретируемыми, что делает их выполнение более медленным, нежели выполнение программ, написанных на языках третьего поколения. Механизм хранимых процедур - один из составных компонентов активного сервера базы данных [2].
В DBS-модели приложение является распределенным. Компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент (реализующий бизнес-функции) оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Преимущества DBS-модели перед RDA-моделью очевидны: это и возможность централизованного администрирования бизнес-функций, и снижение трафика сети, и возможность разделения процедуры между несколькими приложениями, и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры. Однако есть и недостатки.
Во-первых, средства, используемые для написания хранимых процедур, строго говоря, не являются языками программирования в полном смысле слова. Скорее, это - разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональным возможностям с языками третьего поколения, такими как C или Pascal. Они встроены в конкретные СУБД, и, естественно, рамки их использования ограничены. Следовательно, система, в которой прикладной компонент реализован при помощи хранимых процедур, не является мобильной относительно СУБД. Кроме того, в большинстве СУБД отсутствуют возможности отладки и тестирования хранимых процедур, что превращает последние в весьма опасный механизм. Действительно, сколько-нибудь сложная неотлаженная комбинация срабатывания триггеров и запуска процедур может, по меткому выражению одного из разработчиков, "полностью разнести всю базу данных".
Во-вторых, DBS-модель не обеспечивает требуемой эффективности использования вычислительных ресурсов. Объективные ограничения в ядре СУБД не позволяют пока организовать в его рамках эффективный баланс загрузки, миграцию процедур на другие компьютеры-серверы БД и реализовать другие полезные функции. Попытки разработчиков СУБД предусмотреть в своих системах эти возможности (распределенные хранимые процедуры, запросы с приоритетами и т. д.) пока не позволяют добиться желаемого эффекта.
В-третьих, децентрализация приложений (один из ключевых факторов современных информационных технологий) требует существенного разнообразия вариантов взаимодействия клиента и сервера. При реализации прикладной системы могут понадобиться такие механизмы взаимодействия, как хранимые очереди, асинхронные вызовы и т. д., которые в DBS-модели не поддерживаются.
Сегодня вряд ли можно говорить о том, что хранимые процедуры в их нынешнем состоянии представляют собой адекватный механизм для описания бизнес-функций и реализации прикладного компонента. Для того, чтобы превратить их в действительно мощное средство, разработчики СУБД должны воспроизвести в них следующие возможности:
- расширение изобразительный средства языков процедур;
- средства отладки и тестирования хранимых процедур;
- предотвращение конфликтов процедур с другими программами;
-
поддержка приоритетной обработки запросов.
Между тем эти возможности уже реализованы в AS-модели, которая в наибольшей степени отражает сильные стороны технологии "клиент-сервер".
AS-модель
Основным элементом принятой в AS-модели трехзвенной схемы является сервер приложения. В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как служба (service) и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения (Applicaation Client - AC). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. AC обращается с запросом к конкретной службе, но не к AS, то есть серверы приложений обезличены и служат лишь своего рода "рамкой" для оформления служб, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от АС, выстраиваются в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами.
АС трактуется более широко, чем компонент представления. Он может поддерживать интерфейс с конечным пользователем (тогда он является компонентом представления), может обеспечивать поступление данных от некоторых устройств (например, датчиков), может, наконец, сам по себе быть AS. Последнее позволяет реализовать прикладную систему, содержащую AS нескольких уровней. Архитектура такой системы может выглядеть как ядро, окруженное концентрическими кольцами. Ядро состоит из серверов приложений, в которых реализованы базовые прикладные функции. Кольца символизируют наборы AS являющихся клиентами по отношению к серверам нижнего уровня. Число уровней серверов в AS-модели, вообще говоря, не ограничено.
Нетрудно видеть, что AS-модель имеет универсальный характер. Четкое разграничение логических компонентов и рациональный выбор программных средств для их реализации обеспечивают модели такой уровень гибкости и открытости, который пока недостижим в RDA- и DBS-моделях. Именно AS-модель используется в качестве фундамента относительно нового для наших пользователей вида программного обеспечения - мониторов транзакций.
Мониторы транзакций
Мониторы обработки транзакций (Transaction Processing Monitor - TPM), или, проще, мониторы транзакций - программные системы (которые часто относят к категории middleware), обеспечивающие эффективное управление информационно-вычислительными ресурсами в распределенной системе. Они представляют собой гибкую, открытую среду для разработки и управления мобильными приложениями, ориентированными на оперативную обработку распределенных транзакций. В числе важнейших характеристик ТРМ - масштабируемость, поддержка функциональной полноты и целостности приложений, достижение максимальной производительности при обработке данных при невысоких стоимостных показателях, поддержка целостности данных в гетерогенной среде.
Среда разработки приложений
Разработчиков информационных систем ТРМ привлекают возможностью декомпозиции приложений по нескольким уровням с четко очерченными функциями и стандартными интерфейсами, что позволяет создавать легко модифицируемые системы со стройной и целостной архитектурой.
Концетрация чисто прикладных функций в серверах приложений и использование унифицированных интерфейсов с другими логическими компонентами делает прикладную систему практически полностью независимой, во-первых, от конкретной реализации интерфейса с пользователем, и, во-вторых, от необходимого ей менеджера ресурсов. Первое означает, что для реализации компонента представления может быть выбран практически любой удобный и привычный для разработчика инструментарий, будь то Visual Basic, Object Vision или просто С. Следствием второго является то, что менеджер ресурсов (например, СУБД) может быть безболезненно заменен на другой, поддерживающий тот же стандарт интерфейса с прикладной программой - для реляционных СУБД в качестве унифицированного интерфейса используется встроенный (embedded) SQL TMP, функционирующие на множестве платформ (например, TUXEDO System), позволяют разрабатывать приложения, не зависящие ни от конкретной платформы, ни от конкретных средств разработки, ни от конкретных средств коммуникации. Все это заставляет рассматривать их как мощный инструмент для создания полностью мобильных приложений в гетерогенной среде.
Центр проектирования приложений
Фундаментальная характеристика ТРМ - функциональный подход к проектированию бизнес-приложений. Характерное для ТРМ сосредоточение всех прикладных функций в серверах приложений и богатые возможности управления и администрирования превращают их в мощный центр проектирования приложений.
На практике это означает совершенно иной - по сравнению с другими видами программного обеспечения - подход к администрированию, существенно упрощающий обновление бизнес-функций и контроль за их непротиворечивостью. Любые изменения в прикладных функциях осуществляются локально, в сервере приложения, и никак не затрагивают коды клиентов, которых может быть множество. Более того, эти изменения вносятся специалистом - администратором сервера, единственным лицом, отвечающим за функциональность и семантическую целостность приложения. Разработчики программ-клиентов никак не участвуют в процедуре обновления приложения - это выходит за рамки их компетенции. Такой подход позволяет полностью закрыть от разработчиков как детали реализации бизнес-функций, так и собственно правила, по которым работает прикладная система.
Баланс загрузки
Уникальная возможность ТРМ - динамическая настройка параметров системы для достижения требуемой производительности (баланс загрузки) ТРМ поддерживают как статический, так и динамический баланс загрузки. Суть заключается в том, что ТРМ стартует или останавливает AS в зависимости от предопределенных условий и текущего состояния системы. Для оптимизации пропускной способности и времени отклика системы служб ТРМ тиражирует копии процессов-AS на этом же или других узлах, предоставляя тем самым в распоряжении АС необходимые вычислительные ресурсы (в виде дополнительных процессов) для выполнения их запросов.
Масштабируемость
Помимо вертикального и горизонтального масштабирования, ТРМ обеспечивают так называемую матричную масштабируемость. Это - интеграция дополнительных ресурсов в гетерогенную среду в любой ее точке без изменения архитектуры приложения, которое в этой среде функционирует. Достигается это за счет динамической реконфигурации, а на практике означает, что в конфигурацию системы динамически, без остановки серверов приложений, может быть добавлен, например, новый AS, дополнительный менеджер ресурсов или новый компьютер. Очевидно, что матричная масштабируемость практически неограниченно расширяет возможности управления параметрами системы для достижения требуемой производительности.
Оптимальное соотношение цена/производительность
ТРМ обладает возможностями, которые существенно снижают стоимость обработки данных в online-приложениях. Небольшие затраты на приобретение ТРМ с лихвой компенсируются экономией на СУБД. Дело в том, что, как правило, стоимость современных СУБД рассчитывается исходя их числа одновременных подключений. Клиент считается подключенным к СУБД, начиная с момента открытия сеанса с базой данных и заканчивая ее закрытием (хотя в рамках одного подключения некоторые СУБД, например, INGRES, позволяют открыть несколько сеансов с различными БД). В течение сеанса СУБД считает клиента активным и вынуждена хранить контекст его подключения, даже в том случае, если клиент вообще не направляет запросов СУБД, а выполняет свои внутренние функции, либо просто ждет ввода от пользователя (который, быть может, ушел пообедать).
Основная функция ТРМ - обеспечение быстрой обработки запросов, поступающих к AS от множества клиентов (от сотен до многих тысяч). ТРМ выполняет ее, мультиплексируя запросы на обслуживание, направляя их к AS, число которых контролируется им самим. Запросы на обработку данных формируются AS на языке SQL и адресуются СУБД. Между АС и СУБД появляется дополнительный слой (AS), которые выполняют роль мультиплексора. Действительно, АС подключается к AS, передает ему данные для обработки; после того, как AS выполнил требуемые действия, он получает результаты обработки и отключается. Контекст подключения не сохраняется, так как в этом нет никакой необходимости. В то же время клиент обращается с запросами на обслуживание не к СУБД, а к AS, следовательно, СУБД регистрирует и отслеживает подключения AS, но не АС. Однако таких подключений по определению будет гораздо меньше, чем возможных подключений клиентов - хотя бы потому, что сервер приложений предоставляет сервис, разделяемый одновременно несколькими клиентами. Но это позволяет ограничить максимально возможное число одновременных подключений к СУБД, уменьшив тем самым ее стоимость. Фактические данные, приведенные, например, в [3], свидетельствуют о том, что выигрыш в стоимости в приобретении пары "монитор транзакций - СУБД" по сравнению с приобретением только СУБД (как это не кажется парадоксальным) может достигать 50%, при этом производительность может возрасти в несколько раз.
Для понимания идей, заложенных в мониторы транзакций, важно рассмотреть модель обработки распределенных транзакций, которая была предложена USL и принята X/Open в качестве стандарта.
Модель обработки транзакций
Модель X/Open DTP описывает взаимодействие трех субъектов обработки транзакций - прикладной программы (в качестве прикладной программы фигурирует как AS, так и АС), менеджера транзакций (Transaction Manager - TM) и менеджера ресурсов (Recource Manager - RM).
На RM возложено управление информационными ресурсами - будь то файлы, базы данных или что-то другое. Прикладная программа взаимодействует с RM либо с помощью набора специальных функций, либо, если в качестве RM выступает реляционная SQL-ориентированная СУБД - посредством операторов языка SQL, инициируя необходимые операции с данными. Последние оформляются как транзакции, обработку которых берет на себя ТМ. Если с помощью монитора транзакций необходимо решать задачи обработки глобальных транзакций, то место менеджера ресурсов должна занять СУБД, поддерживающая протокол двухфазовый фиксации транзакций и удовлетворяющая стандарту X/Open XA (например, Oracle 7.0, Open INGRES, Informix-Online 5.0).
Роль ТМ в модели X/Open DTP - роль диспетчера, главного координатора транзакций. Он обладает полным набором управления как локальными, так и глобальными транзакциями. В последнем случае транзакция может обновлять данные на нескольких узлах, причем управление данными на них осуществляется, вообще говоря, различными RM. Обработки распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации транзакций, который гарантирует целостность данных в информационной системе, распределенной по нескольким узлам, независимо от того, какой RM управляет обработкой данных на каждом таком узле. Эта уникальная возможность мониторов транзакций как раз и позволяет рассматривать их как своего рода "клей", как средство интеграции в гетерогенной информационной среде.
Понятия транзакции в ТРМ и в традиционных СУБД значительно отличаются. Суть остается одной ("все или ничего"), но в понимании СУБД транзакция - это атомарное действие над базой данных, в то время как в ТРМ транзакция трактуется гораздо шире. Она включает не только операции с данными, но и любые другие действия - передачу сообщений, запись в индексированные файлы, опрос датчиков и т. д. Это позволяет реализовать в ТРМ прикладные транзакции, бизнес-транзакции, что в СУБД, вообще говоря, сделать невозможно.
Функции ТРМ в модели X/Open DTP не ограничиваются только управлением транзакциями. Он берет на себя также координацию взаимодействия клиента и сервера (поэтому иногда его называют Transaction & Communication Manager). При этом используется высокоуровневый интерфейс ATMI (Application Transaction Monitor Interface), представляющий собой набор вызовов функций на языке третьего поколения (например, на языке С). С его помощью разработчик реализует один из нескольких режимов взаимодействия клиента и сервера в рамках расширенной модели "клиент-сервер". Ни AS, ни АС не содержат явных вызовов менеджера транзакций - они включены в библиотечные функции ATMI и невидимы извне. Таким образом, детали взаимодействия прикладной программы и монитора транзакций скрыты от разработчика, что и дает основание говорить об ATMI как о высокоуровневом интерфейсе.
Стандартный способ передачи данных между AC и AS - буфера данных. Они представляют собой определяемые разработчиком структуры данных, память под которые выделяется ТМ. В процессе передачи данных ТМ выполняет различные преобразования (например, согласует формат представления данных при передаче их между машинами с разными архитектурами).
Модель X/Open DTP не описывает в деталях структуру монитора транзакций. Она лишь определяет, из каких компонентов должна состоять любая система DTP и как эти компоненты взаимодействуют друг с другом. Будучи воплощенной в конкретной системе, модель дополняется возможностями, существенно расширяющими традиционные представления о технологии "клиент-сервер". Например, монитор транзакций TUXEDO позволяет организовать взаимодействие АС и AS несколькими способами.
С помощью синхронного вызова tpcall() АС вызывает конкретную службу (один из параметров - имя службы), передает ей исходные данные в буфере и немедленно получает от службы результат обработки. Асинхронный вызов (функция tpcall()) делает то же самое, с тем лишь отличием, что результат обработки возвращается не сразу; клиент запрашивает службу для получения результатов обработки вызовом tpgetrply(). Асинхронный способ взаимодействия позволяет клиенту передать серверу запрос, продолжить работу и получить результаты запроса самостоятельно и в нужный момент времени. Кроме того, поддерживается диалоговый режим взаимодействия, позволяющий сохранять его контекст от сообщения к сообщению. Клиент подключается к серверу (вызов tpconnect()), получая его в монопольное использования до момента окончания диалога (вызов tpdiscon()). Наконец, существует вариант обмена сообщениями между клиентом и сервером через хранимые на диске очереди.
Система управления очередями
Одно из ключевых требований к современным информационным системам - эффективная обработки сообщений. Оно может быть удовлетворено за счет использования систем управления очередями. Разработчики ТРМ обычно включают в арсенал своих систем специальный менеджер ресурсов, отвечающий за управление очередями. Поясним его детали на примере TUXEDO System.
Управление очередями возложено на специальный компонент в составе TUXEDO - менеджер очередей (частный менеджер ресурсов). Помещение в очереди и выборка из них - прерогативы серверов, которые запрашивают менеджер очередей для выполнения соответствующих действий.
Как и в других режимах взаимодействия, в запросе клиент адресуется к конкретной службе. Для каждой из них на диске строятся собственные очередь запросов и очередь ответов. Помещением сообщений в первую и извлечением сообщений из второй ведает сервер TMQUEUE. Сервер TMQFORWARD выбирает сообщения их очереди запросов и помещает сообщения в очередь ответов.
Упрощенно работа с очередями выглядит следующим образом. Клиент посылает запрос конкретной службе, направляя его серверу TMQUEUE (вызов tpenqueue()). Последний помещает сообщение в очередь запросов к данной службе. Сервер TMQFORWARD извлекает сообщение из очереди запросов и направляет его службе (вызов tpcall()). Последняя, выполнив предписанные действия и сформировав ответ на запрос также в виде сообщения, посылает его в очередь ответов. Клиент, при помощи вызова tpdequeue(), запрашивает сервер TMQUEUE на получение сообщения из очереди ответов, что тот и выполняет.
Возможность хранения очередей сообщений в долговременной памяти позволяет говорить о практически стопроцентной надежности взаимодействия клиента и сервера. Даже в случае сбоя компьютера все сообщения с точностью до последнего сохраняются, а их обработка возобновляется с той точки, где произошел сбой. Любые действия с очередями помещаются в тело транзакции. Это обеспечивает полную надежность при доставке сообщений, позволяет доставлять сообщения с уведомлением о получении и реализовать множество полезных функций, необходимых в коммуникационных проектах.
***
На современном рынке мониторов транзакций основными "действующими лицами" являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc), TUXEDO System (USL). Особе место TUXEDO System в этом ряду объясняется несколькими факторами. Система была разработана специалистами USL (компании, ныне поглощенной Novell Inc.), развивалась и совершенствовалась в течение более десяти лет и сегодня фактически приобрела статус стандарта для открытых систем OLTP. Будучи "ветераном" TMP, они послужила прототипом для мониторов транзакций, разработанных крупнейшими поставщиками компьютерных платформ. Ориентация на широкий спектр компьютеров под управлением ОС UNIX позволила системе охватить множество платформ, среди которых AT&T, Amdahl, Bull, Compaq, DataGeneral, Dell, DEC, HP, IBM, ICL, Motorola, NCR, NEC, Pyramid, Sequent, Siemens Nixdorf, Silicon Graphics, Stratus, Su, Tandem, Teradata, Unisys. Компактность кода (около 30 функций ATMI), рациональная архитектура, эффективное использование базовых механизмов ОС UNIX и ряд других привлекательных качеств (в которых автор удостоверился на практике) снискали TUXEDO System популярность среди разработчиков и менеджеров информационных систем.
В России TUXEDO System впервые была представлена на конференции SUUG в 1992 году. Сегодня система доступна для российских разработчиков. Написанию статьи предшествовали многочисленные и плодотворные обсуждения этой темы с Владимиром Елисеевым, им же сделаны ценные замечания по тексту статьи, за что автора выражает глубокую признательность.
1. Глеб Ладыженский. "Система обработки распределенных транзакций TUXEDO", Открытые Системы, Весна 1993.
2. Глеб Ладыженский, Г. Барон. "Ingres - современные тенденции в архитектуре сервера базы данных", Открытые Системы, Осень 1993.
3. The Standish Group. "Client-Server Goes Business Critical. Transaction Processing Monitors, Key to Next Generation of Applications".
Глеб Ладыженский — независимый эксперт (Москва).
