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

«Тонкий» клиент — это самый простой и очевидный способ реализации архитектуры «клиент-сервер», логически происходящий от централизованных систем обработки информации. При этом происходит лишь перенос компонента представления на клиентский компьютер, при этом на само программное приложение возлагаются функции сервера (т. е. оно реализует управленческий и прикладной компоненты). [8]

Тонкий клиент — это самый легкий способ перевода существующих централизованных систем на архитектуру «клиент — сервер». Достаточно перенести пользовательский интерфейс на компьютер пользователя, а само программное приложение будет осуществлять функции сервера (выполнять все процессы приложения и управлять данными).

Как и любая реализация, модель «тонкого клиента» обладает своими недостатками, наиболее ярким из которых является высокая нагрузка на сервер и сеть, вследствие того, что именно на серверной стороне производятся все вычисления, что требует интенсивного обмена данными между клиентским компьютером и сервером. [5]

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

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

К недостаткам подобной реализации архитектуры также относят:

• Трудности реализации, обусловленные низким уровнем гибкости языков типа PL/SQL и отсутствием удобных средств отладки.
• Невысокий уровень производительности программ, написанных на языках типа PL/SQL, в сравнении с приложениями, реализованных на других языках.
• Низкий уровень безопасности программ, созданных с применением языков СУБД; высокая стоимость ошибок.
• Сложности с переносом данных программ на другие платформы

Модель «толстого клиента» позволяет использовать вычислительные мощности клиентских машин, что является актуальным в эпоху распространения персональных компьютеров (Рис.3).

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

При этом на стороне клиента происходит выполнения и компонента представления, и компонента прикладного назначения. На стороне сервера реализуется работа компонента управления транзакциями баз данных.

Реализация приложения в форме модели «толстого» клиента позволяет более рационально использовать имеющиеся вычислительные ресурсы. При этом функции приложения распределены между разными компьютерами, что повышает сложность администрирования подобной системы. Рост количества компьютеров в системе вызывает соответствующее повышение уровня сложности. В целом это повышает затраты на обслуживание системы, как временные, так и финансовые [7].

К другим недостаткам данной модели относят:

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

Распространение языка программирования Java появление загружаемых «апплетов» предоставили возможность создавать клиент-серверные модели, представляющие собой нечто среднее между указанными моделями толстого и тонкого клиентов. Часть функций компонента прикладного назначения стало возможным загружать на клиентский компьютер в форме апплетов Java, что позволяет снижать нагрузку на сервер. При этом пользовательское окружение строилось на основе web-браузера, имеющего возможность запускать апплеты. Но такой подход имеет свои сложности, обусловленные, во многом, дополнительными трудностями администрирования и разработки приложений. Это связано с недостаточной стандартизированностью технологий, применяемых в браузерах [7]. Например, устаревшие версии браузеров, установленные на старых клиентских компьютерах, порой не имеют возможность исполнения апплетов Java.

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

Один из основных вопросов, встающих перед разработчиком двухуровневого приложения является расположение трех основных программных компонентов (представления, прикладного и управления) на двух аппаратных уровнях. Неизбежные компромиссы могут вызывать сложности с уровнем производительности и масштабируемости (при использовании архитектуры «тонкого клиента»), либо с администрированием системы (при использовании «толстого клиента»). [7]

2.2.Трехуровневый вариант архитектуры «клиент — сервер».

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

Его активное развитие началось с середины 90-х годов. При этом информационная система по-прежнему представлена тремя компонентами (представления, прикладной и доступа к данным), но реализация данной модели представлена клиентским приложением («тонкий клиент»), взаимодействующим с сервером приложений, подключенным к серверу базы данных [10].

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

Основная часть бизнес-логики приложения располагается на уровне сервера приложений, представляющего второй уровень модели. Программное обеспечение данного звена выполняет задачи, требующие высокой вычислительной мощности, что позволяет снизить нагрузку на клиентские компьютеры, которые отправляют запросы не напрямую в базу данных, а к промежуточному слою. [9]

Сервер базы данных, представленный, как правило стандартной реляционной или объектно-ориентированной СУБД, является третьим уровнем модели.

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

Рисунок 4. Трехуровневая модель архитектуры «клиент-сервер»

Основным отличием трехзвенной модели клиент-сервер является наличие промежуточного программного обеспечения (middleware), детальный разбор которого будет проведен в отдельной главе (Рис.4).

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

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

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

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

2.3.Многоуровневый вариант архитектуры «клиент-сервер».

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

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

Применение многоуровневой архитектуры целесообразно при использовании информации, хранящейся в нескольких источниках данных. При этом сервер, находящийся между серверами баз данных и сервером с реализованной бизнес-логикой выполняет задачу сбора разрозненных данных и их предоставления в целостном виде серверу приложений (Рис. 5) [9].

Рисунок 5. Многоуровневая архитектура «клиент-сервер».

При этом многоуровневое клиент-серверное приложение достаточно просто разворачивается на базе web-технологий. При этом в качестве клиентской части приложения используется универсальный браузер, а сервер приложений дополняется web-сервером. Вызов процедур сервера приложений создают с помощью технологий Java или Common Gateway Interface (CGI).

CGI – стандарт интерфейса, применяемый для обеспечения связи внешней программы с web-сервером. Программу, работающую по такому интерфейсу совместно с web-сервером, принято называть шлюзом.

Существует классификация, согласно которой в многоуровневой архитектуре выделяют пять уровней [9]:

• Представление
• Уровень представления
• Уровень логики
• Уровень данных
• Данные

Представлению соответствует та информация, которую непосредственно видит пользователь. К ней относятся изображения, сгенерированные html-страницы, таблицы стилей.

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

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

Уровень доступа к данным представлен компонентами, обеспечивающими взаимодействие со сторонними системами, выполняющими задачи, необходимые приложению [5].

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

Как и любая архитектура приложения, многоуровневая имеет смови преимущества и недостатки.

К достоинствами многоуровневой архитектуры относятся: [8]

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

К недостаткам относится [7]:

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