1. Классическая архитектура «клиент-

СЕРВЕР»

Термин "клиент-сервер" означает такую архитектуру программного

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

"запрос-ответ". Если рассмотреть две взаимодействующие части этого комплекса,

то одна из них (клиент) выполняет активную функцию, т. е. инициирует запросы, а

другая (сервер) пассивно на них отвечает.

В вычислительной модели обработки данных «клиент-сервер» несколько

клиентов подключаются к одному серверу. Модель имеет следующие

характеристики:

 возможности обработки распределены между несколькими

машинами;

 сервисы отделены от пользователей;

 серверы выполняют некоторую часть обработки для клиента.

Приложения, используемые в сетях клиент-сервер, производят

предварительную обработку данных (front end), которая выполняется на клиенте, и

обработку, выполняющуюся на сервере (back end).

В модели «клиент-сервер» могут быть использованы:

 автономные (несетевые) приложения, такие как программы

обработки электронных таблиц (spreadsheet) или текстовые

процессоры, которые выполняются на клиенте, но сохраняют

данные на сервере;

 приложения баз данных, которые обеспечивают интерфейс

клиента для запросов и механизм поиска на сервере, который

размещает записи, хранящиеся на одном или нескольких

серверах;

 программы, такие как система электронной почты, в которой

сервер применяется для совместного использования

информации.

Сервер (server в дословном переводе на русский язык означает «тот, кто

обслуживает») предназначен для обслуживания поступающих от клиента (client)

сети запросов. Клиент всегда запрашивает обслуживание, а сервер всегда

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

выступать как в роли клиента, так и в роли сервера, обеспечивая обработку

запросов от других клиентов и запрашивая обслуживание у других серверов.

По способу взаимодействия серверов и клиентов определяют два вида

сетей: «клиент-сервер» (client-server) и «рваный с равным» (peer-to-peer).

Поскольку клиентом сети является пользователь, выполняющий на компьютере

свои задачи, то сам компьютер пользователя, подключенный к сети, называется

«рабочая станция» (workstation).

В модели «клиент-сервер» (рис. 1) рабочие станции формируют запросы на

обслуживание и пересылают их серверу (стадия 1). Сервер, используя свои

вычислительные мощности, обрабатывает запросы (стадия 2). Результаты

обработки возвращаются рабочим станциям (стадия 3). В этой модели максимально

используются все ресурсы сервера, учитывается его специализация. Именно по

такой модели работают серверы приложений и клиенты, использующие эти

приложения.

Рис. 1. Модель клиент-сервер.

Так же возможна ситуация, когда клиенту для реализации одного сервиса

предоставляется как единое целое, не один сервер, а несколько (рис. 2). Этот

вариант особенно хорош для критичных сервисов, для которых недопустима

приостановка обслуживания. Поскольку сервис реализуется сразу несколькими

серверами, остановка одного из них не является критической. Для прекращения

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

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

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

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

плюсами у предложенной модели есть и минусы: самый большой - более сложная

реализация по сравнению с базовой архитектурой. Поскольку все серверы

обеспечивают один и тот же сервис, возникают проблемы либо с репликацией

обрабатываемых данных (поддержание на всех серверах системы актуальной копии

данных), либо с поддержанием целостности распределенных данных.

Рис. 2. Сервер со сложной структурой.

Для осуществления взаимодействия между клиентами и сервером

необходимы правила, которые эти взаимодействия регламентируют, называемые

протоколами. Самые часто используемые протоколы приведены ниже:

 FTP (File Transfer Protocol);

 HTTP (Hyper Text Transfer Protocol);

 SMTP (Simple Mail Transfer Protocol);

 IP (Internet Protocol);

 MySQL Client/Server Protocol;

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

агентов. Идея рассматриваемой модели (рис. 3) состоит в том, что зачастую, как

это ни парадоксально, клиент сам в состоянии выполнить ту задачу, решение

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

задачи, располагаются на клиенте. В таком случае для разгрузки сервера (и очень

часто - для снижения сетевого трафика) целесообразно решать эту задачу на

клиенте. В случае отсутствия у клиента необходимого модуля ПО, его можно

переслать с сервера. Клиент, получив модуль (этот модуль называется мобильным

агентом), может выполнить его локально, решив, таким образом, задачу.

Рис. 3. Мобильные агенты.

В качестве примера можно рассмотреть взаимодействие браузера и веб-

сервера, возвращающего страницу, которая содержит апплет. Апплет также

передается клиенту и выполняется в браузере (т.е. на клиенте), выполняя какие-то

значимые для пользователя действия. Основная проблема для такого подхода

состоит в сложности реализации механизма передачи и выполнения мобильных

агентов, а также контроля безопасности. Однако, современные

средства middleware (Java, например) такими возможностями обладают.

Любая информационная система должна иметь минимум три основные

функциональные части - модули хранения данных, их обработки и интерфейса с

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

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

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

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

программ представления данных и их хранения, можно изменить программы

обработки, например изменив алгоритм полнотекстового поиска. И наконец, не

меняя программ представления и обработки данных, можно изменить программное

обеспечение для хранения данных, перейдя, например, на другую файловую

систему.

В классической архитектуре клиент-сервер приходится распределять три

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

данных располагается на сервере (например, сервере базы данных), интерфейс с

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

распределять между клиентской и серверной частями. В этом заключается

основной недостаток двухуровневой архитектуры, из которого следуют несколько

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

систем.

При разбиении алгоритмов обработки данных необходимо

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

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

понимать эти изменения. Это создает большие сложности при разработке клиент-

серверных систем, их установке и сопровождении, поскольку необходимо тратить

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

действиях разработчиков часто возникают противоречия, а это тормозит развитие

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

Чтобы избежать несогласованности различных элементов архитектуры,

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

на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент, или

архитектура, называемая "2,5- уровневый клиент-сервер"). Каждый подход имеет

свои недостатки. В первом случае неоправданно перегружается сеть, поскольку по

ней передаются необработанные, а значит, избыточные данные. Кроме того,

усложняется поддержка системы и ее изменение, так как замена алгоритма

вычислений или исправление ошибки требует одновременной полной замены всех

интерфейсных программ, а иначе могут возникнуть ошибки или несогласованность

данных.

Если же вся обработка информации выполняется на сервере (когда такое

вообще возможно), то возникает проблема описания встроенных процедур и их

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

декларативным и, следовательно, в принципе не допускает пошаговой отладки.

Кроме того, систему с обработкой информации на сервере абсолютно невозможно

перенести на другую платформу, что является серьезным недостатком. Суть этой

технологии (рис. 3) состоит в том, что клиент выполняет очень ограниченную по

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

устройств и обработка команд рисования). Схема работы подобных систем в

простейшем случае следующая. Клиентская программа передает весь ввод

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

Сервер разбирает и обрабатывает этот ввод и передает клиенту готовые экраны,

которые тот просто отображает (стадия 2). Таким образом, сервер фактически

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

логике клиентского интерфейса.

Рис. 3. Тонкий клиент.

Большинство современных средств быстрой разработки приложений

(RAD), которые работают с различными базами данных, реализует первую

стратегию, т. е. "толстый" клиент обеспечивает интерфейс с сервером базы данных

через встроенный SQL. Такой вариант реализации системы с "толстым" клиентом,

кроме перечисленных выше недостатков, обычно обеспечивает недопустимо

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

операционистам давать права на запись в основную таблицу учетной системы.

Кроме того, данную систему почти невозможно перевести на стремительно

набирающую популярность Web-технологию, так как для доступа к серверу базы

данных используется специализированное клиентское ПО.

Итак, рассмотренные выше модели имеют следующие недостатки.

1. "Толстый" клиент:

 сложность администрирования;

 усложняется обновление ПО, поскольку его замену нужно

производить одновременно по всей системе;

 усложняется распределение полномочий, так как

разграничение доступа происходит не по действиям, а по

таблицам;

 перегружается сеть вследствие передачи по ней

необработанных данных;

 слабая защита данных, поскольку сложно правильно

распределить полномочия.

2. "Тонкий" клиент:

 усложняется реализация, так как языки типа PL/SQL не

приспособлены для разработки подобного ПО и нет хороших

средств отладки;

 производительность программ, написанных на языках типа

PL/SQL, значительно ниже, чем созданных на других языках,

что имеет важное значение для сложных систем;

 программы, написанные на СУБД-языках, обычно работают

недостаточно надежно; ошибка в них может привести к

выходу из строя всего сервера баз данных;

 получившиеся таким образом программы полностью

непереносимы на другие системы и платформы.

Для решения перечисленных проблем используются многоуровневые (три и

более уровней) архитектуры клиент-сервер.