Технология модели «клиент-сервер»

Технология модели  
«клиент-сервер»

Роли

 

• Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса
• Компьютер, желающий воспользоваться ресурсов – клиентом.
• Программы – аналогично
• Можно для одного ресурса выполнять роль клиента, для другого - сервера

4 группы функций приложения:

 

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

 

Логические компоненты приложения:

 

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

Различия в реализациях технологии  «клиент-сервер» 

 

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

 

Выделяются четыре подхода, реализованные  в моделях:

 

• модель файлового сервера  
  (File Server – FS);
• модель доступа к удаленным данным (Remote Access Data – RDA);
• модель сервера базы данных  
  (DataBase Server – DBS);
• модель сервера приложений  
  (Application Server – AS).

 

Файловый сервер (FS)

 

Компонент представления

 

Прикладной компонент

 

 
файлы 


 

Компонент  
доступа  
к ресурсам

 

Клиент

 

Сервер

Файловый сервер (FS)

 

• Высокий трафик (передача множества файлов, необходимых приложению)
• Узкий спектр операций манипуляции с данными («данные – это файлы»)
• Отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы) и т.д.

Модель доступа к удаленным  ресурсам (RDA)

 

SQL

 

Компонент представления

 

Прикладной компонент

 

 
данные 


 

Компонент доступа  
к ресурсам

 

Клиент

 

Сервер

Модель доступа к удаленным  ресурсам (RDA)

 

• унификация интерфейса «клиент-сервер» в виде языка SQL
• перенос компонента представления и прикладного компонента на компьютеры-клиенты существенно разгружает сервер БД
• администрирование приложений практически невозможно из-за совмещения в одной программе различных по своей природе функций (функции представления и прикладные).

Модель сервера базы данных (DBS)

 

Вызов

 

Компонент представления

 

 
данные 


 

Прикладной компонент

 

Компонент доступа к ресурсам

 

Клиент

 

Сервер

Модель сервера базы данных (DBS)- особенности

 

• Основа - механизм хранимых процедур. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL–сервер.
• Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

 

Модель сервера базы данных (DBS)- достоинства

 

• Возможность централизованного администрирования прикладных функций
• Снижение трафика (вместо SQL–запросов по сети направляются вызовы хранимых процедур)
• Возможность разделения процедуры между несколькими приложениями, и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.

 

Модель сервера базы данных (DBS) - недостатки

 

• Ограниченность средств, используемых для написания хранимых процедур, которые представляют собой разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональными возможностями с языками третьего поколения, такими как C++ или Pascal.
• Сфера их использования ограничена конкретной СУБД, в большинстве СУБД отсутствует возможность отладки и тестирования хранимых процедур.

 

Наилучший результат – RDA + DBS

 

• Поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель),
• Более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте

Модель сервера приложений

 

Компонент представления

 

 
API 


 

Прикладной  
компонент

 

 
 


 

Компонент доступа к ресурсам

 

Клиент

 

Сервер

 

Сервер

Модель сервера приложений

 

• Прикладной компонент выделен как важнейший изолированный элемент приложения
• Для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами.

 

АКТИВНЫЙ СЕРВЕР

 

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

 

Активный сервер включает в  себя:

 

• процедуры базы данных;
• правила (триггеры);
• события в базе данных;
• типы данных, определяемые пользователем.

 

Процедуры базы данных

 

• Общие части (часто используемые) прикладных программ оформляются в отдельные процедуры, которые хранятся непосредственно в базе данных.
• Одна процедура может использоваться несколькими прикладными программами.
• Сокращаются затраты на написание прикладных программ – они составляются из готовых процедур.
• Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры.

 

Правила (триггеры)

 

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

 

События в базе данных

 

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

 

События в базе данных

 

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

 

Типы данных, определяемые пользователями

 

• Описание нового типа данных хранится в базе данных и его обработка происходит так же, как и обработка стандартных типов данных.