 |
Архитектура «клиент-сервер»
|
|
|
|
Новая модель взаимодействия компьютеров в сети получила название «клиент-сервер». Каждый из составляющих эту архитектуру элементов играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент - имеет возможность воспользоваться ими.
Сервер базы данных представляет собой мультипользователь-скую версию СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. В его задачу входит реализация логики обработки транзакций с применением необходимой техники синхронизации - с поддержкой протоколов блокирования ресурсов, с обеспечением предотвращения и (или) устранения тупиковых ситуаций.
В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Программное обеспечение рабочей станции при такой архитектуре играет роль только внешнего интерфейса (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-модель является фундаментом для мониторов обработки транзакций.
|
|
|
