В чем особенность создания приложений в архитектуре клиент-сервер?

Одна из моделей взаимодействия компьютеров в сети получила название «клиент-сервер» (Рис. 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-модель является фундаментом для мониторов обработки транзакций.