Основные особенности архитектуры «клиент-сервер»
Одна из моделей взаимодействия компьютеров в сети получила название «клиент-сервер» (Рис. 1.). Каждый из составляющих эту архитектуру элементов играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность воспользоваться ими.
Рис. 1. Архитектура «клиент-сервер»
Сервер базы данных представляет собой мультипользовательскую версию СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. В его задачу входит реализация логики обработки транзакций с применением необходимой техники синхронизации - поддержки протоколов блокирования ресурсов, обеспечение, предотвращение и/или устранения тупиковых ситуаций.
В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Программное обеспечение рабочей станции при такой архитектуре играет роль только внешнего интерфейса (Front - end) централизованной системы управления данными. Это позволяет существенно уменьшить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить рабочие станции и при достаточно мощной центральной машине использовать для них более дешевое оборудование.
Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они входят в состав или образуют систему распределенной обработки данных.
Для современных СУБД архитектура «клиент-сервер» стала фактически стандартом. Если предполагается, что проектируемая информация будет иметь архитектуру «клиент-сервер», то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, т. е. часть функций приложений будет реализована в программе-клиенте, другая - в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы:
функции ввода и отображения данных;
прикладные функции, характерные для предметной области;
фундаментальные функции хранения и управления ресурсами (базами данных);
служебные функции.
Исходя из этого деления любое приложение может состоять из следующих компонентов:
компонент представления (функции 1-й группы);
прикладной компонент (функции 2-й группы);
компонент доступа к информационным ресурсам (функции 3-ей группы и протокол их взаимодействия).
Различия определяются четырьмя факторами:
какие виды программного обеспечения в логических компонентах;
какие механизмы программного обеспечения используются для реализации функций трех групп;
как логические компоненты распределяются компьютерами в сети;
какие механизмы используются для связи компонент между собой.
Исходя из этого, рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».
FS-модель
Базовая для локальных сетей персональных компьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.
Основные свойства:
выделяется файл-сервер для реализации услуг по обработке файлов других узлов сети; работает под управлением сетевых ОС;
играет роль компонент доступа к информационным ресурсам;
в остальных узлах функционирует приложение, в кодах которого совмещены компоненты представления и прикладной;
протокол обмена - набор низкоуровневых вызовов.
Технология: запрос направляется на файловый сервер, который передает СУБД, размещенной на компьютере-клиенте, требуемый блок данных. Вся обработка осуществляется на компьютере-клиенте.
Недостатки:
высокий сетевой трафик;
небольшое число операций манипулирования;
недостаточные требования к безопасности.
RDA-модель
Основные свойства:
коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте;
доступ к информационным ресурсам обеспечивается операторами непроцедурного языка SQL.
Технология:
клиентский запрос направляется на сервер, где функционирующее ядро СУБД обрабатывает запрос и возвращает результат (блок данных) клиенту. Ядро СУБД выполняет пассивную роль;
инициатор манипуляций с данными - программы на компьютере-клиенте.
Достоинства:
процессор сервера загружается операциями обработки данных;
уменьшается загрузка сети, т.к. по сети передаются запросы на языке SQL;
унификация интерфейса «клиент-сервер» в виде языка SQL; использование его в качестве стандарта общения клиента и сервера.
Недостатки:
удовлетворительное администрирование приложений в RDA-модели невозможно из-за совмещения в одной программе различных по своей природе функций (представления и прикладных).
DBS-модель
Реализована в реляционных СУБД Informix, Ingres, Oracle.
Основные свойства:
основа модель-механизм хранимых процедур - средство программирования SQL-сервера;
процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на компьютере, где функционирует SQL-сервер;
компонент представления выполняется на компьютере-клиенте;
прикладной компонент и ядро СУБД на компьютере-сервере базы данных.
Достоинства:
возможность централизованного администрирования;
вместо SQL-запросов по сети передаются вызовы хранимых процедур, что ведет к снижению сетевого трафика.
Недостатки:
в большинстве СУБД недостаточно возможностей для отладки и типизирования хранимых процедур;
ограниченность средств для написания хранимых процедур.
На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем.
AS-модель
Основные свойства:
на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем;
этот процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента приложения (АС);
прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (AS);
все операции над БД выполняются соответствующим компонентом, для которого AS - клиент.
RDA- и DBS-модели имеют в основе двухзвенную схему разделения функций. В RDA-модели прикладные функции отданы клиенту, в DBS-модели их реализация осуществляется через ядро СУБД. В RDA-модели прикладной компонент сливается с компонентом представления, в DBS-модели интегрируется в компонент доступа к ресурсам.
В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, имеющий стандартизированные интерфейсы с двумя другими компонентами.
AS-модель является фундаментом для мониторов обработки транзакций.