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

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

2.2. Классическая двухуровневая архитектура «Клиент - сервер»

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

Технология клиент-сервер представляет собой архитектуру программного комплекса, в котором прикладная программа разделена на два логически различных компонента (клиент и сервер), взаимодействующих по схеме «запрос-ответ» и решающих свои конкретные задачи (Рис.2).

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

Компьютер (или программа), который управляет и/или владеет ресурсом, называется сервером этого ресурса.

Компьютер (или программа), который запрашивает и использует каждый ресурс называется клиентом этого ресурса.

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

- модули пользовательского интерфейса;

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

- модули хранения данных;

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

- модули обработки данных (Функции управления ресурсами);

Эта группа также называется логикой доступа к данным или алгоритмами доступа к данным.

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

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

Следующие компоненты выделены в каждом приложении в соответствии с функциональным подразделением:

- Компонент просмотра данных;

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

- Компонент управления ресурсами.

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

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

Чтобы избежать несогласованности различных элементов архитектуры были созданы две модификации двухзвенной архитектуры «Клиент - сервер»: «Толстый клиент» («Тонкий сервер») и «Тонкий клиент» («Толстый сервер»).[8, с.112]

В данных архитектурах разработчики попытались выполнять обработку данных на одной из двух физических частей - либо на стороне клиента («Толстый клиент»), либо на сервере («Тонкий клиент).

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

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

ESDI до сих пор представляет собой классическую двухуровневую архитектуру" клиент-сервер", тогда необходимо помнить следующее :

- архитектура «Толстый сервер» аналогична архитектуре «Тонкий клиент» (Рисунок 3).

Передача запроса от клиента на сервер, обработка запроса сервером и передача результата клиенту.

Рис. 3 - Архитектура «Тонкий клиент»

В этом случае архитектуры имеют следующие недостатки:

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

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

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

- программы, полученные таким образом, совершенно нетерпимы к другим системам и платформам.

- архитектура тонкого сервера аналогична архитектуре толстого клиента (Рис. 4).

Запрос обрабатывается на стороне клиента, т. е. все исходные данные передаются от сервера к клиенту. В этом случае архитектуры имеют следующие недостатки:

- трудно уточнить програмное обеспечение потому что его необходимо заменить в тоже время через всю систему;

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

- перегружает сеть, передавая необработанные данные;

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

Рис. 4 - Архитектура «Толстый клиент»

Для решения этих задач используется многоуровневая (три и более уровней) клиент-серверная архитектура.

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

2.3. Различные модели технологии «Клиент - сервер»

Самой первой базовой технологией для локальных сетей являлась модель файлового сервера (FS). В свое время данная технология была очень среди отечественных разработчиков, использовавших такие системы, как FoxPro, Clipper, Clarion, Paradox и так далее.

В модели FS функции всех трех компонентов (компонент представления, компонент приложения и компонент доступа к ресурсам) объединяются в одном коде, который выполняется на компьютере-сервере (узле). Клиентский компьютер в этой архитектуре вообще отсутствует, а ввод и вывод данных происходит через терминал или компьютер в режиме эмуляции терминала. Приложения обычно разрабатываются на языке четвертого поколения (4GL). Один из компьютеров в сети считается файловым сервером и предоставляет другим компьютерам услуги по обработке файлов. Он работает под сетевой операционной системы и играет роль компонента для доступа к источникам информации. На других компьютерах в сети работает приложение, в котором объединены компонент отображения и компонент приложения.

Технология взаимодействия клиента и сервера выглядит следующим образом: запрос направляется на файловый сервер, который передает СУБД, размещенной на компьютере-клиенте, требуемый блок данных. Вся обработка осуществляется на терминале (Рис. 5).

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

Рис. 5 - Модель файлового сервера

Преимуществами данной технологии являются:

- простота разработки приложений;

- удобство администрирования и обновления ПО из-за компактного расположения всех компонентов на одном компьютере;

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

Но преимущества FS-модели перекрывают ее недостатки:

- большая загрузка сети;

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

- дорогостоящее серверное оборудование, так как все пользователи делятся своими ресурсами;

- нет GUI.[10, с.124]

Благодаря решению проблем, присущих технологии файлового сервера, была внедрена более продвинутая технология под названием "Клиент-Сервер".

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

Разница в реализации приложений в клиент-серверной технологии определяются четырьмя факторами:

Типы программного обеспечения в логических компонентах;

- какие программные механизмы используются для реализации функций логических компонентов;

- как логические компоненты компьютеров распределены по сети;

- какие механизмы используются для соединения компонентов друг с другом.

Исходя из этого, выделяются три подхода, каждый из которых реализован в соответствующей модели технологии «Клиент - сервер»:

- модель доступа к удаленным данным (Remote Date Access - RDA);

- модель сервера базы данных (DateBase Server - DBS);

- модель сервера приложений (Application Server - AS).

Рассмотрим функции и характеристики различных моделей технологии «Клиент-сервер».

Модель доступа к удаленным данным (RDA) - сетевая архитектура технологии «Клиент - сервер», при которой коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Доступ к информационным ресурсам обеспечивается при помощи непроцедурного языка (например ,SQL – запросов для баз данных) или вызовами функций специальной библиотеки (если имеется специальный интерфейс прикладного программирования - API).

Запросы к информационным ресурсам направляются по сети удаленному компьютеру, который обрабатывает и выполняет их, возвращая клиенту блоки данных (рисунок 6).

Рис. 6 - Модель доступа к удаленным данным

Модель RDA имеет ряд ограничений.

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