Клиент-серверные архитектуры распределенной обработки данных

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

• клиентской, которая отвечает за целевую обработку данных и организацию взаимодействия с пользователем;

• серверной, которая обеспечивает хранение данных, обраба­тывает запросы и посылает результаты клиенту для специ­альной обработки.

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

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

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

Основной принцип технологии «клиент—сервер» заключается разделении функций стандартного интерактивного приложения на четыре группы, имеющие различ­аю природу:

• функции ввода и отображения данных;

• чисто прикладные функции, характерные для данной предметной области (например, для банковской системы — открытие счета, перевод денег с одного счета другой и т. д.);

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

• служебные, играющие роль интерфейсов между функциями первых трех групп.

Выделяются четыре основных подхода, реализованные в сле­дующих моделях (или схемах):

• файловый сервер (File Server — FS);

• доступ к удаленным данным (Remote Data Access — RDAV,

• север базы данных (DataBase Server — DBS);

• сервер приложений (Application Server — AS).

Файловый сервер (FS)

Модель является базовой для локальных сетей персональных компьютеров. В свое время она была исключительно популяр­ной среди отечественных разработчиков, использовавших такие системы, как FoxPRO, Clipper, Clarion, Paradox и т. д. Один из компьютеров в сети считается файловым сервером и предостав­ляет услуги по обработке файлов другим компьютерам. Здесь мы имеем дело с распределенной файловой системой. Файловый сер­вер работает под управлением сетевой операционной системы (например, Novell NetWare) и играет роль компонента доступа к информационным ресурсам (т. е. к файлам). На других компью­терах в сети функционируют приложения, в кодах которых со­вмещены компонент представления и прикладной компонент (рис. 7.1, а). Протокол обмена представляет собой набор низко­уровневых вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.

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

К технологическим недостаткам модели относят высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипулирования данны­ми («данные — это файлы»), отсутствие адекватных средств безопасности доступа к данным (зашита только на уровне фай­ловой системы) и т. д. Собственно, перечисленное не есть не­достатки, но следствие внутренне присущих FS-модели ограни­чений, определяемых ее характером. Недоразумения возникают в том случае, когда FS-модель используют не по назначению – например, пытаются интерпретировать как модель сервера базы данных.

Удаленный доступ (RDA)

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

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

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

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

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

Сервер баз данных (DBS)

Наряду с RDA-моделью все большую популярность приобре­тает DBS-модель (рис. 7.1, в). Последняя реализована в некото­рых реляционных СУБД (Informix, Ingres, Sybase, Oracle). Ее ос­нову составляет механизм хранимых процедур — средство про­граммирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и вы­полняются на том же компьютере, где функционирует SQL-сер­вер. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

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

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

Сервер приложений (AS)

В AS -модели (рис. 7.1, г) процесс, выполняющийся на ком­пьютере-клиенте, отвечает обычно за интерфейс с пользователем (т. е. реализует функции первой группы). Обращаясь за выпол­нением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client — АС). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server — AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, по от­ношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов — базы дан­ных, очереди, почтовые службы и др.

RDA- и DBS-модели опираются на двухзвенную схему разде­ления функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выпол­нение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во вто­ром — интегрируется в компонент доступа к информационным ресурсам. В AS-модели реализована трехзвенная схема разделе­ния функций, где прикладной компонент выделен как важней­ший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной опера­ционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мо­ниторов обработки транзакций (Transaction Processing Monitors — ТРМ) или, проще мониторов транзакций, которые выделяются особый вид программного обеспечения. В заключение отметим, что часто, говоря о сервере базы данных подразумевают как компьютер, так и программное обеспечение – ядро СУБД. При описании архитектуры «клиент—сервер» под сервером базы данных мы имели в виду компьютер. Ниже сервер базы данных будет пониматься как программное обеспечение — ядро СУБД.