1.2. Архитектуры клиент—сервер в технологии управления удаленными базами данных

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

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

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

• прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);

• функции обработки данных внутри приложения (DataBase Logic);

• функции управления информационными ресурсами (DataBase Manager System);

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

Структура типового приложения, работающего с базой дан­ных в архитектуре клиент—сервер, приведена рис. 1.1.

Как видно из рис. 1.1, клиентская часть приложения включает в себя следующие части:

• презентационную логику;

• бизнес-логику, или логику собственно приложений;

• логику обработки данных;

• процессор управления данными.

Презентационная логика (Presentation Logic) как часть прило­жения определяется тем, что пользователь видит на своем экра­не, что приложение работает. Сюда относятся все интерфейсные экранные формы, которые пользователь видит или заполняет в ходе работы приложения, а также все то, что выводится пользо­вателю на экран в качестве результатов решения некоторых про-

Клиент

Рис. 1.1. Структура типового приложения, работающего с базой данных

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

• формирование экранных изображений;

• чтение и запись в экранные формы информации;

• управление экраном;

• обработка движений мыши и нажатие клавиш клавиатуры.

Бизнес-логика, или логика собственно приложений (Business

Processing Logic), — это часть кода приложения, которая опреде­ляет собственно алгоритмы решения конкретных его задач. Обыч­но этот код записывается с использованием различных языков программирования, таких как С, С++, Visual Basic и др.

Логика обработки данных (Data Manipulation Logic) — это часть кода приложения, которая непосредственно связана с обработ­кой данных внутри него. Далными управляет собственно СУБД, а для обеспечения доступа к ним используется язык SQL.

Процессор управления данными (DataBase Manager System Processing) — это собственно СУБД, которая обеспечивает хра­нение и управление базами данных. В идеале функции СУБД дол­жны быть скрыты от бизнес-логики приложения, однако при рас­смотрении архитектуры приложения мы выделим их в отдельную его часть.

Рис. 1.2. Распределение функций компонентов приложения в моделях

клиент—север

В централизованной архитектуре (Host-Based Processing) ука­занные части приложения располагаются в единой среде и ком­бинируются внутри одной исполняемой программы. В децентра­лизованной архитектуре эти части приложения могут быть по-раз­ному распределены между серверным и клиентским процессами.

В зависимости от характера распределений задач можно выде­лить следующие их модели (рис. 1.2):

• распределенное представление (Distribution Presentation);

• удаленное представление (Remote Presentation);

• распределенная бизнес-логика (Remote Business Logic);

• удаленное управление данными (Remote Data Management);

• распределенное управление данными (Distributed Data Management).

Эта условная классификации показывает, как могут быть рас­пределены отдельные задачи между серверным и клиентскими процессами. В данной классификации отсутствует реализация удаленной бизнес-логики, так как считается, что она не может быть удалена полностью, а может быть лишь распределена меж­ду разными процессами, которые могут взаимодействовать друг с другом.