Cистемы «клиент\сервер»

Уже само понятие "архитектура «клиент-сервер»" трактуется разработчиками по-разному. Все сходятся лишь в одном: для организации вычислительного процесса при распределенной обработке данных желательно использование архитектуры «клиент-сервер». Так, фирма R-Style Software Lab определяет архитектуру «клиент-сервер» как модель взаимодействия компьютеров и процессов в сети (классификацию моделей рассмотрим ниже).

• ODBC (Open DataBase Connectivity) - открытый стандарт совместимости баз данных;
• CASE-технология (Computer-Aided Software/System Engineering) - компьютерная разработка программ и систем;
• SQL (Structure Query Language) - язык структурных запросов. 

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

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

Обычно выделяются три модели взаимодействия клиента и сервера:

• RDA (Remote Data Access), в которой компонента представления (пользовательский интерфейс) и прикладная компонента (логика работы программы) совмещены в клиентской части, а компонента доступа к информационным ресурсам (данным) размещена в серверной части.
• DBS (DataBase Server), в которой компонента представления размещена в клиентской части, а прикладная компонента и доступ к информационным ресурсам - в серверной;
• AS (Application Server), в которой компонента представления находится в клиентской части, прикладная компонента - в "сервере приложения", а компонента доступа к информационным ресурсам - в "сервере базы данных".

Системы с архитектурой «клиент-сервер» могут быть двух- или трехуровневыми.

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

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

Легко видеть, что трехуровневая система относится к модели AS.

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

Безусловно, такая архитектура применительно к SQL-серверам имеет преимущества:

• Увеличение производительности при тех-же характеристиках сервера
• Использование общего кэша при операциях ввода-вывода
• Меньший объем используемой памяти
• Большее количество обслуживаемых пользователей при том-же объеме памяти
• И недостатки -  меньшая защищенность сервера при внутренних сбоях.

Последний пункт относится ко всем SQL-серверам, имеющим архитектуру SuperServer. Действительно, все потоки (threads) находятся в одном адресном пространстве, и любой сбой может привести к "падению" SQL-сервера.

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

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