Файл: Технология «клиент-сервер» (Клиент — сервер).pdf

2.4 Двухуровневая модель архитектуры клиент-сервер

Такая архитектура получила свое развитие в начале 1990-х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы.

Изначально эта системы строилась на стандартной двухуровневой клиент-серверной системе (архитектуре). Двухуровневая клиент-серверная архитектура основана только на использовании сервера базы-данных (DB-сервера), когда клиентская часть содержит уровень представления данных, а на сервере располагается БД вместе с СУБД и прикладными программами.

DB-сервер отличается от файл-сервера тем, что в его оперативной памяти, помимо сетевой ОС, функционирует СУБД, которая обеспечивает совместное использование рабочими устройствами базы данных, размещенной во внешней памяти данного DB-сервера. Он предоставляет возможность отказаться от перепосылке по сети файлов данных целиком и передавать только то, что позходит запросу пользователя. В этом случае возможно разделение пользовательского приложения на две части: первая выполняется на сервере и связана с выборкой данных из БД, а вторая часть по представлению данных для анализа и принятия решения выполняется на клиентском компьютере. Поэтому, увеличивается сумарная производительность такой информационной системы после объединения вычислительных ресурсов сервера и клиентской станции.

Обращение к БД осуществляется на языке SQL, который стал стандартом для БД. Поэтому сервер БД называют SQL-сервером, который поддерживается всеми реляционными СУБД (Informix, Oracle, ADABAS D, InterBase, SyBase, MS SQL, и др.)

Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.). При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер, который обеспечивает возможность пересылки и преобразования данных из глобальной БД в структуру БД клиентского приложения.

Позднее была разработана концепция активного сервера, в котором была заложена система – механизм хранимых процедур. Это позволило часть прикладного компонента перенести на сервер (модель распределенного приложения).

В словаре базы данных хранятся процедуры, они разделяются между несколькими клиентами и выполняются на одном и том же компьютере, что и SQL-сервер.

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

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

Концепция локального кэширования БД является частным случаем концепции реплицированных БД. Как и в общем случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно содержать компонент управления базами данных – упрощенный вариант сервера баз данных, который, например, может не обеспечивать многопользовательский режим доступа. Отдельная проблема, это связь кэшей и общей базы данных. Здесь возможны различные решения – от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной уровень.

Достоинства такой архитектуры:

- допускается централизованное управление прикладными функциями,

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

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

-все данные хранятся на сервере, который защищен гораздо лучше компьютеров клиентов, также на сервере легче обеспечить контроль полномочий, для того, чтобы доступ к данным имели клиенты с соответствующими правами;

-возможность работы в многопользовательском режиме;

- целостность данных.

Недостатоки этой архитектуры:

- ограниченность технологий разработки хранимых процедур с языками общего вида и назначения (C и Pascal). На практике обычно используют смешанный подход: простые прикладные функции выполняются сохраненными процедурами на сервере;

- наиболее сложные прикладные функции выполняются на клиенте в прикладной программе

- вся работоспособность вычислительной сети зависит от работоспсобности сервера;

- для управления системой требуется квалифицированный профессионал;

- высокая стоимость оборудования;

- бизнес логика приложений осталась в клиентском программном обеспечении.

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

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

Данный вид так же называют архитектурой с "толстым" клиентом. Здесь бизнес-логика и логика представления данных размещены на клиенте, который (когда сервером является СУБД) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL. Но необходимость установки "толстых клиентов", требующих большого количества специальных библиотек и особой настройки окружения, на широкое число пользовательских компьютеров с различными операционными системами, несомненно, вызывает массу проблем.

В качестве альтернативы появилась также двухзвенная архитектура "с тонким клиентом". В этом случае, в идеале программа-клиент реализует только графический интерфейс пользователя (GUI) и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеальном случае, клиентом является просто интернет-браузер, который имеется в стандартной операционной системе любого пользовательского компьютера, а так же не требует особой настройки и установки специального ПО. К сожалению, такая схема тоже не без недостатков, потому, что серверу иногда приходится брать на себя несвойственные для него задачи реализации бизнес логики приложения (к примеру, серверу СУБД приходится выполнять расчеты).

2.5 Многоуровневая архитектура клиент-сервер.

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

Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура (трехзвенная архитектура, three-tier), имеющая в наличии наличие следующие компоненты: клиентское приложение ( «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

Клиент не должен иметь прямых связей с базой данных (по условию безопасности), быть под нагрузкой основной бизнес-логикой (по требованиям масштабности) и хранить состояние приложения (по требованиям надежности). На первый уровень возможно вынесение и обычно выносится простейшая бизнес-логика: система авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, простые операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.

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

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

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

В "правильной" (по безопасности, надежности, масштабности) структуре сервер базы данных находится на отдельном компьютере, к которому по сети подсоединены один или несколько серверов приложений, к которым, по сети подключаются терминалы.

Плюсы данной архитектуры:

• в администрировании не нуждается клиентское ПО;
• масштабируемость;
• конфигурируемость
• высокая безопасность;
• высокая надежность;
• не высокие требования к скорости передачи данных в канале между терминалами и сервером приложений;
• низкие требования к производительности и техническим характеристикам терминалов;
• снижение стоимости терминалов.

Минусы этой архитектуры:

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

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

В лучшем случае:

• программа-клиент образует GUI, передает запросы серверу приложений и принимает от него ответ,
• сервер приложений реализует бизнес-логику и обращается с запросами к серверу "третьего уровня" (например, серверу базы данных за данными),
• сервер третьего уровня обслуживает запросы сервера приложений.
• Программа-клиент, таким образом, может быть "тонкой".

Преимущества данной архитектуры очевидны:

• на каждом из звеньев можно независимо вносить изменения;
• уменьшается нагрузка на сеть, так как звенья не передают между собой большими объемами информации;
• обеспечивается простая модернизация оборудования и программного обеспечения;
• приложения создаются на стандартных языках третьего или четвертого поколения (Java, C/C++).

Следующим логическим шагом - являеся увеличение колличества звеньев. Современные корпоративные программные системы представляют сложные системы взаимодействующих на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.

Главной проблемой систем, основанных на двухзвенной архитектуре "клиент-сервер", или тем более на многозвенной архитектуре, является то, что от них требуется мобильность в наиболее широком классе аппаратно-программных сред. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется различная аппаратура и протоколы связи. Создания систем, поддерживающих все возможные протоколы, приводит к перегрузке, приносит ущерб функциональности. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах существует различная адресация, представление чисел, кодировка и другие криптографические ньюансы. Это наиболее существенно влияет на сервера высокого уровня: телекоммуникационных, вычислительных, баз данных.