Архитектура «клиент-сервер»

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

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

В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Про­граммное обеспечение рабочей станции при такой архитектуре игра­ет роль только внешнего интерфейса (Front—end) централизованной системы управления данными. Это позволяет существенно умень­шить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить ра­бочие станции и при достаточно мощной центральной машине ис­пользовать для них более дешевое оборудование.

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

Для современных СУБД архитектура «клиент-сервер» стала фак­тически стандартом.

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

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

прикладные функции, характерные для предметной области;

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

служебные функции.

Исходя из этого деления любое приложение может состоять из следующих компонентов:

компонент представления (функции первой группы);

прикладной компонент (функции второй группы);

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

Различия определяются четырьмя факторами:

какие виды программного обеспечения в логических компонен­тах;

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

как логические компоненты распределяются компьютерами в сети;

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

Исходя из этих допущений рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».

1. FS-моделъ — базовая для локальных сетей персональных ком­пьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.

Основные требования:

выделяется файл-сервер для реализации услуг по обработке фай­лов других узлов сети; работает под управлением сетевых ОС;

играет роль компонент доступа к информационным ресурсам;

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

протокол обмена — набор низкоуровневых вызовов;

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

Недостатки:

высокий сетевой трафик;

небольшое число операций манипулирования;

недостаточные требования к безопасности.

2. RDA-модель.

Основные требования:

коды компонента представления и прикладного компонента сов­мещены и выполняются на компьютере-клиенте;

доступ к информационным ресурсам обеспечивается оператора­ми непроцедурного языка SQL.

Технология:

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

инициатор манипуляций с данными — программы на компьюте­ре-клиенте.

Достоинства:

процессор сервера загружается операциями обработки данных;

уменьшается загрузка сети, так как передаются по сети запросы на языке SQL;

унификация интерфейса «клиент-сервер» в виде языка SQL; использование его в качестве стандарта общения клиента и сервера.

Недостатки:

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

3. DBS-модель, — реализована в реляционных СУБД Informix,

Ingres, Oracle.

Основные требования:

основа модель-механизм хранимых процедур — средство про­граммирования SQL-сервера;

процедуры хранятся в словаре базы данных; разделяются между несколькими клиентами и выполняются на компьютере, где функ­ционирует SQL-сервер;

компонент представления выполняется на компьютере-клиенте, прикладной компонент и ядро СУБД — на компьютере-сервере базы данных.

Достоинства:

возможность централизованного администрирования; вместо SQL-запросов по сети передаются вызовы хранимых про­цедур, что ведет к снижению сетевого трафика. Недостатки:

в большинстве СУБД недостаточно возможностей для отладки и типизирования хранимых процедур;

ограниченность средств для написания хранимых процедур. На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем.

4. AS-модель. Основные требования:

на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем;

этот процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента приложения (АС);

прикладной компонент реализован как группа процессов, вы­полняющих прикладные функции, и называется сервером приложе­ния (AS);

все операции над БД выполняются соответствующим компонен­том, для которого AS — клиент.

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

AS-модель является фундаментом для мониторов обработки транзакций.