Файл: INTRANET и архитектура «клиент-сервер».pdf

Клиентское приложение

Данные

Клиентское приложение

пересылки запросов

и результатов

Рис.2.Архитектура «клиент-сервер»

1.1.4 Серверы баз данных

«Сервер баз данных» - этот термин используют для обозначения СУБД, которая основана на «клиент-сервер» архитектуре, включая в т.ч., клиентскую и серверную части. Данные системы предназначены для хранения и обеспечения доступа к базам данных^[16]. Обычно одна база данных вся хранится в одном узле сети и ее поддерживает один сервер, серверы баз данных - дешевое приближение к распределенным базам данных, т.к. общая база данных доступна для всех пользователей локальной сети.

1.1.5 Принципы взаимодействия между клиентскими и серверными частями

Доступ к базе данных от пользователя или приложения созидается путем обращения к клиентской части системы. Как основной интерфейс между серверной и клиентской частями выдвигается речь баз данных SQL. Это язык - текущий стандарт интерфейса СУБД в открытых системах. Наименование SQL-сервер относится к серверам баз данных, которые основаны на SQL^[17].

Серверы баз данных, интерфейс которых основан на языке SQL, имеют преимущества и недостатки. Преимущество - стандартность интерфейса. Клиентские части любой SQL-ориентированной СУБД могли бы функционировать с любым SQL-сервером самостоятельно от производителя последнего.

При таком уровне интерфейса между серверной и клиентской частями системы на стороне клиента функционирует мало программ СУБД. Это обычно, если на стороне клиента применяется маломощная рабочая станция. Если клиентский компьютер располагает высокой мощностью, возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом системы^[18]. Одним из перспективных направлений СУБД гибкое конфигурирование системы, разделение функций между клиентской и пользовательской частями СУБД обусловливается при установке системы.

1.1.6.Преимущества протоколов удаленного вызова процедур

Протоколы удаленного вызова процедур важны в системах управления базами данных, которые основаны на «клиент-сервер» архитектуре^[19].

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

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

1.1.7 Типовое разделение функций между клиентами и серверами

Обычно на стороне клиента СУБД работает такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL. Иногда хочется включить в состав клиентской части системы некоторые функции для работы с «локальным кэшем» базы данных, т.е. с той ее частью, с которой активно используется клиентской прикладной программой^[20]. Это можно выполнить путем формального создания на стороне клиента локальной копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов. С другой стороны, можно перенести большую часть прикладной системы на сторону сервера, но если разница в мощности клиентских рабочих станций и сервера велика. При использовании RPC это нетрудно сделать. Нужно, чтобы базовое программное обеспечение сервера это разрешало. При использовании ОС UNIX проблем нет.

1.1.8 Архитектуры процессора базы данных

Основная часть любой системы «клиент-сервер» - это сервер БД. Со времен возникновения «клиент-сервер» архитектуры появились варианты архитектуры процессора БД, т.к. он во многом определяет успех всей системы^[21]. Основное требование к серверу БД - обеспечение минимального времени выполнения запросов при возможном максимальном числе пользователей. Существуют 2 основные архитектуры для построения процессора БД: многопоточная архитектура и архитектура с несколькими процессами.

1.2. Архитектура с несколькими процессами

Характеризуется тем, что несколько экземпляров исполняемого файла, работающих одновременно. Системы отличаются хорошей масштабируемостью, хотя и требуют значительных затрат памяти, т.к. память каждому экземпляру приложения отдельно выделяется. Архитектура подразумевает наличие эффективного механизма взаимодействия процессов и полагается на операционную систему при разделении процессорного времени между отдельными экземплярами приложения. Пример сервера, построенного по этой архитектуре, - Oracle Server. Когда пользователь подключается к БД Oracle, он запускает отдельный экземпляр исполняемого файла БД.

Многопоточная архитектура

Эта архитектура использует лишь один исполняемый файл с несколькими потоками выполнения. Преимущество - скромные к внедрению требования, чем для архитектуры с несколькими процессами. Сервер берет на себя разделение времени между отдельными потоками, иногда отдавая преимущество некоторым задачам над другими. Отпадает необходимость в сложном механизме взаимодействия процессов. Так, по данной архитектуре построены MS SQL Server и Sybase SQL Server.

Трехуровневая архитектура «клиент-сервер»

На верхнем уровне абстрагирования взаимодействия клиента и сервера достаточно можно выделить компоненты:

• презентационная логика (Presentation Layer - PL) предназначена для работы с данными пользователя;

• бизнес-логика (Business Layer - BL) предназначена для проверки правильности данных, поддержки и т.д.;

• логика доступа к ресурсам (Access Layer - AL), предназначена для хранения данных.

Сервер БД Пользовательский интерфейс

Данные Бизнес-логика

Пользовательский интерфейс

Бизнес-логика

Рисунок 3. «Толстый» клиент. (fat client)

Вариант реализации архитектуры клиент-сервер во внедренных системах. Данная модель подразумевает объединение в клиентском приложении как PL, так и BL, так как обеспечивается децентрализация управления бизнес-логикой. При необходимости выполнения изменений в клиентском приложении надо менять исходный код. Серверная часть при данном подходе представляет сервер БД, который реализует AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.

Бизнес-логика Пользовательский интерфейс

Данные

Пользовательский интерфейс

Рисунок 4. «Тонкий» клиент. (thin client)

Модель используют в корпоративной среде, в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, поэтому клиент довольствуется скромной аппаратной платформой, а сервер объединяет BL и AL. Максимальный сервер предусматривает выполнение бизнес-логики с помощью хранимых процедур сервера (хранимые процедуры - откомпилированные SQL-инструкции на сервере). Это позволяет максимально централизовать контроль над данными и изменять правила работы для всего предприятия.

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

Промежуточный сервер

Пользовательский интерфейс

Бизнес-логика

другого уровня

Сервер БД Пользовательский интерфейс

Бизнес-логика

Данные

Рисунок 5. Сервер бизнес-логики. (Трехуровневая архитектура)

Из модели с физически выделенным в отдельное приложение блоком BL получаем трехуровневую архитектуру «клиент-сервер». На сервере БД может функционировать «универсальная» часть бизнес-логики. Данная схема позволяет поддерживать клиентов на пользовательских компьютерах и разгрузить сервер БД от загрузки при сохранении гибкой системы работы с бизнес-правилами. Так промежуточный сервер может использоваться другой SQL-сервер, но рационально можно задействовать персональную СУБД, она менее требовательна к аппаратным ресурсам и может обеспечить удобные средства построения и поддержки бизнес-логики.

1.2.1 Персональные СУБД

Для разработки клиентских приложений вместо универсальных средств разработки удобнее использовать персональные СУБД. Использование персональных СУБД позволяет организовывать работу с бизнес-правилами и поддерживать независимую работу клиентского приложения за счет собственных форматов хранения данных. Краткая характеристика некоторых персональных СУБД - в таблице.

Краткая характеристика некоторых персональных СУБД