Двухзвенные модели распределения функций

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

Наиболее типичными вариантами (см. приложение Е ) разделения функций между компью­тером-сервером и компьютером-клиентом являются следующие: распределенное представление; удаленное представление; распределенная функция; удаленный доступ к данным; распределенная БД.

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

Рассмотрим сначала модели удаленного доступа к данным и удаленного представ­ления (сервера БД) как наиболее широко распространенные.

В модели удаленного доступа к данным (Remote Data Access - RDA) програм­мы, реализующие функции представления информации и логику прикладной обра­ботки, совмещены и выполняются на компьютере-клиенте. Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовом функций специальной библиотеки API (Application Programnimg Interface - интерфейса прикладного программирования).

Основное достоинство RDA-модели состоит в большом обилии готовых СУБД, имеющих SQL-интерфейсы. и существующих инструментальных средств, обеспечи­вающих быстрое создание программ клиентской части. Средства разработки чаще всего поддерживают графический интерфейс пользователя в MS Windows, стандарт интер­фейса ODBC и средства автоматической генерации кода. Подавляющее большинство средств разработки использует языки четвертого поколения.

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

Модельсервера БД (DataBase Server - DBS) отличается от предыдущей модели тем, что функции компьютера-клиента ограничиваются функциями представления информации, в то время как прикладные функции обеспечиваются приложением, находящимся на компьютере-сервере. Эта модель является более технологичной чем RDA-модель и применяется в таких СУБД, как Ingress, Sybase и Oracle. При этом приложения реализуются в виде хранимых процедур.

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

Достоинствами модели DBS являются: возможность хорошего централизованно­го администрирования приложений на этапах разработки, сопровождения и модификации, а также эффективное использование вычислительных и коммуникационных ресурсов. Последнее достигается за счет того, что выполнение программ в режиме коллектив­ного пользования требует существенно меньших затрат на пересылку данных в сети[11].

Один из недостатков модели DBS связан с ограничениями средств разработки хра­нимых процедур. Основное ограничение - сильная привязка операторов хранимых процедур к конкретной СУБД. Язык написания хранимых процедур, по сути, является процедурным расширением языка SQL, и не может соперничать по выразительным средствам и функциональным возможностям с традиционными языками третьего по­коления, такими, как С и Pascal. Кроме того, в большинстве СУБД нет удовлетвори­тельных средств отладки и тестирования хранимых процедур, что делает их механизм опасным инструментом - неотлаженные программы могут приводить к некорректнос­тям БД, зависаниям серверных и клиентских программ во время работы системы и т. и.

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

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

СУБД подобного рода могут иметь место в сетях, поддерживающих работу так назы­ваемых Х-терминалов. В них основной компьютер (хост-машина) должен иметь доста­точную мощность, чтобы обслуживать несколько Х-терминалов. X-терминал тоже дол­жен обладать достаточно быстрым процессором и иметь достаточный объем оператив­ной памяти (дисковые накопители отсутствуют). Часто Х-терминалы создают на базе RISC-компьютеров (restricted [reduced] instruction set computer) - компьютеров с сокра­щенным набором команд. Все программное обеспечение находится на хост-машине, Про­граммное обеспечение Х-терминала, выполняющее функции управления представлени­ем и сетевые функции, загружается по сети с сервера при включении Х-терминала,

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

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

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

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

Модель распределенной БД предполагает использование мощного компьютера-клиента, причем данные хранятся на компьютере-клиенте и на компьютере-сервере. Взаимосвязь обеих баз данных может быть двух разновидностей:

а) в локальной и удаленной базах хранятся отдельные части единой БД;

б) локальная и удаленная БД являются синхронизируемыми друг с другом копиями.

Достоинством модели распределенной БД является гибкость создаваемых па ее основе ИС, позволяющих компьютеру-клиенту обрабатывать локальные и удален­ные БД. При наличии механизмов координации соответствия копий система в целом, кроме того, обладает высокой живучестью, так как разрыв соединения клиента и сер­вера не приводит к краху системы, а ее работа может быть восстановлена с возобнов­лением соединения. К недостатку модели можно отнести высокие затраты при вы­полнении большого числа одинаковых приложений на компьютерах-клиентах.

 

2 Трехзвенная модель распределения функций и сложные схемы взаимодействия

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

Рассматриваемая нами модель имеет название модель сервера приложений, или AS-модель (Application Server) (см. рис.5 приложение Ж).

Согласно трехзвенной AS-модели, отвечающий за организацию диалога с конеч­ным пользователем процесс, как обычно, реализует функции представления информации и взаимодействует с компонентом приложения также, как в модели DBS. Ком­понент приложения, располагаясь на отдельном компьютере, в свою очередь, связан, с компонентом управления данными подобно модели RDA.

Центральным звеном AS-модели является сервер приложений. На сервере приложе­ний реализуется несколько прикладных функций, каждая из которых оформлена как служ­ба предоставления услуг всем требующим этого программам. Серверов приложений мо­жет быть несколько, причем каждый из них предоставляет свой вид сервиса. Любая про­грамма, запрашивающая услугу у сервера приложений, является для него клиентом. По­ступающие от клиентов к серверам запросы помещаются в очередь, из которой выбира­ются в соответствии с некоторой дисциплиной, например, по приоритетам.

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

Рисунок 1.- Трехзвенная модель сервера приложений

 

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

Основной не­достаток модели - более высокие затраты ресурсов компьютеров на обмен информа­цией между компонентами приложения по сравнению с двухзвенными моделями.

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

Возможно также, что в распределенной вычислительной системе при работе с БД имеются множественные связи (статические), когда один объект по отношению к од­ним является клиентом, а по отношению к другим - сервером (см. рис. 7 приложение Ж).

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

 

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

Как отмечалось, наиболее гибкой и универсальной моделью распределения функ­ций СУБД является АS-модель. Она описывает взаимодействие трех основных эле­ментов: клиента, сервера приложений и сервера БД, но не затрагивает вопросы орга­низации функционирования программного обеспечения при обработке информации, в частности при выполнении транзакций. Для преодоления этого недостатка пред­ложена модель монитора транзакций.

Мониторы обработки транзакций (Transaction Processing Monitor - ТРМ), или мониторы транзакций, представляют собой программные системы категории проме­жуточного слоя (Middleware), обеспечивающие эффективное управление информа­ционно-вычислительными ресурсами в распределенной вычислительной системе. Основное их назначение - организация гибкой, открытой среды для разработки и управления мобильными приложениями, оперативно обрабатывающими распреде­ленные транзакции. Применение мониторов транзакций наиболее эффективно в ге­терогенных вычислительных системах[13].

Приложение ТРМ позволяет выполнять масштабирование системы, поддерживать функциональную полноту и целостность приложений а также повысить производи­тельность обработки данных при невысокой стоимости накладных расходов. Принципы организации обработки информации с помощью монитора транзакций описываются моделью монитора транзакций X/Open DTP (Distributed Transaction Processing - обработка распределенных транзакций). Эта модель (см. приложение З) включает в себя три объекта: прикладную программу, менеджер ресурсов (Resource Manager - RM.) и монитор, или менеджер, транзакций (Transaction Manager - ТМ).

Рисунок 2 - Модель обработки транзакций X/Open DTR

 

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

Интерфейс ATMI (Application Transaction Monitor Interface - интерфейс мони­тора транзакций приложения) позволяет вызывать функции ТРМ на некотором язы­ке программирования, например, С.

Функции менеджера ресурсов обычно выполняют серверы БД или СУБД. В задачах организации управления обработкой распределенных транзакций (транзакций, затрагива­ющих программные объекты вычислительной сети) ТМ взаимодействует с RM, который должен поддерживать протокол двухфазной фиксации транзакций и удов­летворять стандарту Х/Ореn ХА. Примерами СУБД, поддерживающих протокол двухфаз­ной фиксации транзакции, являются Oracle 7.0, Open INGRES и Informix-Online 5.0.

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

Модель X/Open DTP не раскрывает структуру ТМ в деталях, а определяет состав компонентов распределенной системы обработки информации и как эти компоненты взаимодействуют друг с другом. Практические реализации этой модели, естественно, могут отличаться друг от друга. В числе примеров реализации мониторов транзакций можно назвать ACMS, CICS, и TUXEDO System.

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

Прикладные программы становятся практически независимыми от конкретной ре­ализации интерфейса с пользователем и от менеджера ресурсов. Первое означает, что для реализации функций представления можно выбрать любое удобное и привычное для разработчика средство (от языка С до какой-либо CASE-системы). Независи­мость от менеджера ресурсов подразумевает возможность легкой замены одного ме­неджера ресурсов на другой, лишь бы они поддерживали стандарт взаимодействия с прикладной программой (для СУБД - язык SQL).

Если ТРМ поддерживает множество аппаратно-программных платформ, как например, TUXEDO System, то разрабатываемые приложения становятся, кроме того, мобильными.

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

Для пользователей распределенных систем ТРМ позволяют улучшить пока­затели пропускной способности и времени отклика, снизить стоимость обработки данных в оперативном режиме на основе эффективной организации вычислитель­ного процесса[14].

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

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

Кроме того, администраторы систем получают возможность снизить общую сто­имость программного обеспечения систем клиент-сервер. Снижение стоимости мож­но достигнуть простым уменьшением количества подключений к серверам БД.

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