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

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

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

рис. 5.4 .

Рис. 5.4. Представление многоуровневой архитектуры "клиент-сервер"

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

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

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

Плюсами данной архитектуры являются [ , , , ]:

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

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

1. Представление;
2. Уровень представления;
3. Уровень логики;
4. Уровень данных;
5. Данные.

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

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

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

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

Данные системы обычно хранятся в базе данных.

5.1.6. Архитектура распределенных систем

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

Схематически такую архитектуру можно представить, как показано на рис. 5.6 .

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

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

Технология клиент-сервер считается одним из "китов" современного мира компьютерных сетей. Но задачи, для решения которых она была разработана, уходят в прошлое. Новые задачи и технологии требуют переосмысления принципов клиент-серверных систем. Одна из таких технологий World Wide Web. Web-технология является развитием архитектуры клиент-сервера, т.е. с помощью одного клиента можно подключиться ко многим серверам. Информационная система, кроме интерфейса, должна иметь уровни обработки данных и их хранения. Проблема разработчиков интерсетей в согласовании работы Web с другими элементами системы, например базами данных. Одним из перспективных способов решения этой проблемы - многоуровневые системы клиент-сервер.

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

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

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

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

В классической архитектуре клиент-сервер три основные части приложения распределяются по двум физическим модулям. Обычно ПО хранения данных располагается на сервере (/: сервере базы данных), интерфейс с пользователем - на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями. В этом основной недостаток данной архитектуры. Разбиение алгоритмов обработки данных требует синхронизации действий обеих частей системы. Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент, или "2,5-уровневый клиент-сервер"). Каждый подход имеет свой недостаток: в первом случае неоправданно перегружается сеть, т.к. по ней передаются необработанные (избыточные) данные, усложняется поддержка и изменение системы, так как замена алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ, иначе последует несогласованность данных; во втором случае , когда вся обработка информации выполняется на сервере, возникает проблема описания встроенных процедур и их отладки (описание является декларативным и не допускает пошаговой отладки). Кроме того, систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу.

Большинство современных средств быстрой разработки приложений (RAD), которые работают с различными БД, реализует первую модель ("толстый" клиент), обеспечивающую интерфейс с сервером БД через язык SQL.. Этот вариант, кроме выше перечисленных недостатков, имеет низкий уровень безопасности.

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

Недостатки рассмотренных выше моделей:

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

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

F сложность в обновлении ПО, т.к. его замену необходимо производить одновременно по всей системе;

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

F перегрузка сети из-за передачи по ней необработанных данных;

F слабая защита данных.

2. "Толстый" сервер

ð усложняется реализация, так как языки PL/SQL не приспособлены для разработки подобного ПО и нет средств отладки;

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

ð программы, написанные на СУБД-языках, работают ненадежно, что может привести к выходу из строя всего сервера БД;

ð созданные таким образом программы полностью непереносимы на другие системы и платформы.

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

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

Например. Можно выделить сервер управления персоналом, который будет выполнять все необходимые для управления персоналом функции. Связав с ним отдельную БД, можно скрыть от пользователей все детали реализации этого сервера, разрешив обращаться только к его общедоступным функциям. Такая система проще адаптируется к Web, т.к. легче разработать html-формы для доступа пользователей к определенным функциям БД, чем ко всем данным.

В трехуровневой модели "тонкий" клиент не перегружен функциями обработки данных, а выполняет основную роль системы представления информации, поступающей с сервера приложений. (Такой интерфейс реализуется с помощью стандартных средств Web-технологии - браузера, CGI и Java). Это уменьшает объем данных, передаваемых между клиентом и сервером приложений, позволяя подключать клиентов с медленными телефонными каналами.

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

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

Менеджеры транзакций

МТ - позволяют одному серверу приложений одновременно обмениваться данными с несколькими серверами БД. Хотя серверы Oracle имеют механизм выполнения распределенных транзакций, но если пользователь хранит часть информации в БД Oracle, часть в БД Informix, а часть в текстовых файлах, то без МТ не обойтись. МТ используется для управления распределенными разнородными операциями и согласования действий различных компонентов информационной системы. Любое сложное ПО требует использования МТ.

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

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

Логически МТ делится на несколько частей:

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

· менеджер транзакций (управляет распределенными операциями);

· менеджер ведения журнальных записей (следит за восстановлением и откатом распределенных операций);

· менеджер блокировок (обеспечивает правильный доступ к совместно используемым данным).

Обычно М-коммуникационный объединен с М-авторизации, а М-транзакций с М-блокировок и системных записей. Причем такой М редко входит в комплект поставки, поскольку его функции (ведение записей, распределение ресурсов и контроль операций), как правило, выполняет сама БД (например, Oracle).

Наибольшие изменения произошли в М-коммуникации, так как в этой области появились новые объектно-ориентированные технологии (CORBA, DCOM и т.д.). Многоуровневая модель клиент-сервер позволяет существенно упростить распределенные вычисления, делая их не только более надежными, но и более доступными.

4.4. Системы технологической почты ­ -

это гарантированная доставка информации и средство для интеграции приложений

Проектирование информационных систем ставит перед системными аналитиками решения следующих проблем:

ð распределенность системы;

ð интеграция различных приложений;

ð удобство администрирования.

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

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

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

Один из них основывается на концепции соединения (рис.1), а другой - на идее обмена сообщениями.

1

Рис.1. Механизм взаимодействия с установлением соединения

Процесс взаимодействия приложений и использованием установления соединения можно разделить на три фазы:

1. установление соединения;

2. передача информации;

3. закрытие соединения.

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

Системы, построенные на принципе обмена сообщениями, используют при взаимодействии технологию очередей сообщений (рис.2).

Рис.2. Взаимодействие приложений с использованием технологии очередей сообщений

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

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

Преимvшecтвa использования СТП:

Ø Гарантированность доставки сообщения. Серверы очередей сообщений

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

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

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

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

Архитектура клиент - сервер (client-server architecture) - это концепция информационной сети, в которой основная часть ее ресурсов сосредоточена в серверах, обслуживающих своих клиентов. Рассматриваемая архитектура определяет два типа компонентов: серверы и клиенты .

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

Рисунок Архитектура клиент - сервер

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

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

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

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

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

В сетях с выделенным файловым сервером на выделенном автономном ПК устанавливается серверная сетевая операционная система . Этот ПК становится сервером. Программное обеспечение (ПО ), установленное на рабочей станции, позволяет ей обмениваться данными с сервером. Наиболее распространенные сетевые операционная системы:

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

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

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

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

Позволяют организовывать сети с большим количеством рабочих станций;

Обеспечивают централизованное управление учетными записями пользователей, безопасностью и доступом, что упрощает сетевое администрирование;

Эффективный доступ к сетевым ресурсам;

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

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

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

Требуют квалифицированного персонала для администрирования;

Имеют более высокую стоимость сетей и сетевого оборудования.

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

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

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

Рис.1. Компоненты сетевого приложения

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

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

Автономная система (компьютер, не подключенный к сети) представляет все эти компоненты как на различных уровнях (ОС, служебное ПО и утилиты, прикладное ПО), так и на уровне приложений (не характерно для современных программ). Так же и сеть — она представляет все эти компоненты, но, в общем случае, распределенные между узлами. Задача сводится к обеспечению сетевого взаимодействия между этими компонентами.

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

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

В любой сети (даже одноранговой), построенной на современных сетевых технологиях, присутствуют элементы клиент-серверного взаимодействия, чаще всего на основе двухзвенной архитектуры . Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером).

Рис.2. Двухзвенная клиент-серверная архитектура

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

Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:

• сервер терминалов — распределенное представление данных;
• файл-сервер — доступ к удаленной базе данных и файловым ресурсам;
• сервер БД — удаленное представление данных;
• сервер приложений — удаленное приложение.

Перечисленные модели с вариациями представлены на .

Рис.3. Модели клиент-серверного взаимодействия

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

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

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

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

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

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

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

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

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

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

Рис.4. Трехзвенная клиент-серверная архитектура

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

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

1. Представление данных — на стороне клиента.
2. Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).
3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

Рис.5. Многозвенная (N-tier) клиент-серверная архитектура

Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier) путем выделения дополнительных серверов, каждый из которых будет представлять собственные сервисы и пользоваться услугами прочих серверов разного уровня. Абстрактный пример многозвенной модели приведен на .

Сравнение архитектур

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

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

1. Высокую степень гибкости и масштабируемости.
2. Высокую безопасность (т.к. защиту можно определить для каждого сервиса или уровня).
3. Высокую производительность (т.к. задачи распределены между серверами).

Клиент-серверные технологии

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

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

Для доступа к тем или иным сетевам сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:

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

В последнее время все чаще используется еще один термин: «rich»-client . «Rich«-клиент своего рода компромисс между «толстым» и «тонким» клиентом. Как и «тонкий» клиент, «rich»-клиент также представляет графический интерфейс, описываемый уже средствами XML и включающий некоторую функциональность толстых клиентов (например интерфейс drag-and-drop, вкладки, множественные окна, выпадающие меню и т.п.)

Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.

Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:

• XAML (eXtensible Application Markup Language) — разработан Microsoft, используется в приложениях на платформе.NET;
• XUL (XML User Interface Language) — стандарт, разработанный в рамках проекта Mozilla, используется, например, в почтовом клиенте Mozilla Thunderbird или браузере Mozilla Firefox;
• Flex — мультимедийная технология на основе XML, разработанная Macromedia/Adobe.

Заключение

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

Контрольные вопросы

1. В чем заключается основная идея К-С взаимодействия?
2. В чем отличия между понятиями «клиент-серверная архитектура» и «клиент-серверная технология»?
3. Перечислите компоненты К-С взаимодействия.
4. Какие задачи выполняет компонент представления в К-С архитектуре?
5. С какой целью средства доступа к БД представлены в виде отдельного компонента в К-С архитектуре?
6. Для чего бизнес-логика выделена как отдельный компонент в К-С архитектуре?
7. Перечислите модели клиент-серверного взаимодействия.
8. Опишите модель «файл-сервер».
9. Опишите модель «сервер БД».
10. Опишите модель «сервер приложений»
11. Опишите модель «сервер терминалов»
12. Перечислите основные типы серверов.

Постоянный адрес этой страницы:

Перевод с английского: Чернобай Ю. А.

Развитие клиент-серверных систем

Архитектура компьютерной системы развилась наряду со способностями аппаратных средств использовать запускаемые приложения. Самой простой (и самой ранней) из всех была «Mainframe Architecture», в которой все операции и функционирование производятся в пределах серверного (или "host") компьютера. Пользователи взаимодействовали с сервером через «dumb» терминалы, которые передали инструкции, захватив нажатие клавиши, серверу и показали результаты выполнения инструкций для пользователя. Такие приложения носили типичный характер и, несмотря на относительно большую вычислительную мощность серверных компьютеров, были в основном относительно медленными неудобными в использовании, из-за необходимости передавать каждое нажатие клавиши серверу.

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

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

Обычно для обмена данными между клиентом и сервером используется либо Structured Query Language (SQL) либо Remote Procedure Call (RPCs). Ниже описаны несколько основных вариантов организации архитектуры клиент-сервер.

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

Рисунок 1: Двухуровневая архитектура

Распределение логики приложения и обработки данных в этой модели был и остается проблематичным. Если клиент «smart» и проводит основную обработку данных то появляются проблемы, связанные с распространением, установкой и обслуживании приложения, поскольку каждый клиент нуждается в собственной локальной копии программного обеспечения. Если клиент «dumb» применение логики и обработки должны быть реализованы в базе данных, а, следовательно, он становится полностью зависимым от конкретной используемой СУБД. В любом случае, каждый клиент должен пройти регистрацию и в зависимости от полученных им прав доступа выполнять определенные функции. Тем не менее, двухуровневая архитектура клиент-сервер была хорошим решением, когда количество пользователей было относительно небольшим (примерно до 100 одновременно работающих пользователей), но с ростом пользователей появился ряд ограничений на использование этой архитектуры.

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

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

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

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

Но, несмотря на это, двухуровневая архитектура нашли новую жизнь в эпоху интернета. Она может хорошо работать в разъединенной окружающей среде, где UI является «dumb» (например браузер). Однако, во многих отношениях это реализация представляет собой возврат к первоначальной архитектуре мэйнфреймов.

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

Рисунок 2: Трехуровневая архитектура

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

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

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

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

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

Рисунок 3: N-уровневая архитектура

Уровни против слоев

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

Главное, что нужно помнить о многоуровневой архитектуре является то, что запросы и ответы каждого потока в одном направлении проходят по всем слоям, и что слои никогда не может быть пропущены. Таким образом, в модели, показанной на рисунке 4, единственный слой, который может обратиться к слою "E" (слой доступа к данным) является слой "D" (слой правил). Аналогичным образом слой "C" (прикладной слой ратификации) может только отвечать на запросы из слоя "B" (слоя обработка ошибок).

Рисунок 4: Ряды разделены на логические слои