Структура клиент серверной архитектуры. Клиент-серверная двухуровневая архитектура ис

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

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

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-серверы Изначально представляли доступ к гипертекстовым документам по протоколу HTTP (Huper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности работу с бинарными файлами (изображения, мультимедиа и т.п.). Серверы приложений Предназначены для централизованного решения прикладных задач в некоторой предметной области. Для этого пользователи имеют право запускать серверные программы на исполнение. Использование серверов приложений позволяет снизить требования к конфигурации клиентов и упрощает общее управление сетью. Серверы баз данных Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом СУБД находится на сервере, к которому и подключаются клиентские приложения. Файл-серверы Файл-сервер хранит информацию в виде файлов и представляет пользователям доступ к ней. Как правило файл-сервер обеспечивает и определенный уровень защиты от несакционированного доступа. Прокси-сервер Во-первых, действует как посредник, помогая пользователям получить информацию из Интернета и при этом обеспечивая защиту сети. Во-вторых, сохраняет часто запрашиваемую информацию в кэш-памяти на локальном диске, быстро доставляя ее пользователям без повторного обращения к Интернету. Файрволы (брандмауэры) Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с целью обеспечения безопасности сети. Почтовые серверы Представляют услуги по отправке и получению электронных почтовых сообщений. Серверы удаленного доступа (RAS) Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема.

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

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

«Тонкий» клиент Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через 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. Перечислите основные типы серверов.

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

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

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

Классическая архитектура клиент-сервер

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

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

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

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

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

Большинство современных средств быстрой разработки приложений (RAD), которые работают с различными базами данных, реализует первую стратегию, т. е. "толстый" клиент обеспечивает интерфейс с сервером базы данных через встроенный SQL. Такой вариант реализации системы с "толстым" клиентом, кроме перечисленных выше недостатков, обычно обеспечивает недопустимо низкий уровень безопасности. Например, в банковских системах приходится всем операционистам давать права на запись в основную таблицу учетной системы. Кроме того, данную систему почти невозможно перевести на Web-технологию, так как для доступа к серверу базы данных используется специализированное клиентское ПО.

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

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

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

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

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

перегружается сеть вследствие передачи по ней необработанных данных;

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

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

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

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

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

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

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

Многоуровневые архитектуры клиент-сервер

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

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

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

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

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

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

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

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

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

менеджер авторизации (Authorisation Manager) обеспечивает аутентификацию пользователей и проверку их прав доступа;

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

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

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

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

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

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

Материал для статьи предоставлен компанией ASoft; тел. 261-5724. С Валерием Коржовым можно связаться по адресу .

БД В АРХИТЕКТУРЕ «КЛИЕНТ-СЕРВЕР»

План лекции

1. Клиенты и серверы локальных сетей

2. Системная архитектура клиент-сервер

3. Модели рабочих нагрузок в архитектуре клиент/сервер

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

Т. Конноли. Базы данных. Проектирование, реализация и сопровождение. Теория и практика.: Пер. с англ. – М.: Изд. дом «Вильямс», 2006. – 1440 с.

1 Клиенты и серверы локальных сетей

В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Развитие этой идеи приводит к функциональному выделению компонентов сети: рабочих станций и серверов локальной сети. Сервер локальной сети (server) предоставляет ресурсы (услуги) рабочим станциям и/или другим серверам. Рабочая станция (клиeнты (client)) - кoмпьютepы, ocyщecтвляющиe дocтyп к ceтeвым pecypcaм, пpeдocтaвляeмым cepвepoм.

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

· файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций и в случае запроса фaйл или дaнныe цeликoм кoпиpyютcя нa зaпpaшивaющий кoмпьютep;

· сервер приложений выпoлняет пpиклaдныe чacти клиeнт-cepвepныx пpилoжeний, a тaкжe содержит дaнныe, дocтyпныe клиeнтaм;

2 Системная архитектура «клиент-сервер»

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

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

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

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

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

1) функции диалога (Presentation Logic, PL) или компонент визуализации . Компонент визуализации прикладной задачи осуществляет ввод информации пользователем с помощью тех или иных средств, а также вывод информации на экран и печать. Компонент визуализации для архитектуры клиент-сервер всегда исполняется на рабочем месте пользователя (поскольку должен же он наблюдать какие-либо результаты работы программы). Для организации презентационной логики преимущественно используется модель графического интерфейса пользователя GUI (User Interface Graphical) или Web-интерфейс;

2) прикладные функции или это часть кода приложения с алгоритмами обработки данных (Business Logic, BL). Компонент прикладной логики решает собственно ту или иную задачу, связанную с обработкой данных в той или иной предметной области и представляет собой алгоритмы реакции приложения на действия пользователя или на внутренние события, правила обработки данных. Этот компонент может быть распределен между клиентской и серверной частью различным образом в зависимости от применяемой модели. Обычно этот код программируется на языках программирования высокого уровня: C, C++, Visual Basic, Object Pascal и т. п.;

3) функции обработки данных внутри приложения (Database Logic, DL) - это часть кода приложения, связанная с выборкой и манипулированием данными (данными управляет собственно СУБД). Подъязыком является язык SQL.

Типовая структура приложения «клиент-сервер»

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

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

3 Модели рабочих нагрузок в архитектуре клиент/сервер

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

· «интеллектуальные» клиенты (толстый клиент - тонкий сервер);

· «интеллектуальный» сервер (тонкий клиент - толстый сервер);

· смешанные системы;

· многоуровневые системы.

DIV_ADBLOCK80">

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

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

Достоинства:

· увеличение производительности работы ИС: бизнес-логика выполняется в том же адресном пространстве, что и код доступа к базе данных, и, кроме того, тесно интегрирован с механизмом поиска данных. Это означает, что данные не нужно перемещать или копировать перед обработкой, а значит, сетевой трафик минимизируется;

· на сервере легче обеспечить целостность данных;

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

Недостатки:

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

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

Достоинства смешанных систем:

· серверный код одновременно доступен многим клиентам, что снижает накладные расходы при выполнении однотипных запросов;

· эффективность работы клиентов меньше зависит от сетевого трафика.

Недостатки:

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

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

Достоинства многоуровневых систем:

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

· централизованная модификация бизнес-правил;

Недостатки:

· увеличивается сетевой трафик.

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

4 Уровни и модели архитектуры «клиент-сервер»

С точки зрения количества составных частей клиент-серверные системы делятся на двухуровневые и трехуровневые.

Двухуровневые системы состоят только из клиента и сервера К двухуровневым моделям архитектуры «клиент-сервер» относятся:

1) модель файлового сервера (FS-модель);

2) модель удаленного доступа (RDA-модель);

3) модель активного сервера (DBS-модель).

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

Архитектура «файл-сервер»

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

На сервере находятся файлы с данными и поддерживается доступ к файлам.

В этой модели клиент обращается к серверу с запросом к данным. Запрос клиента формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд, Система управления файлами (СУФ) считывает запрашиваемые данные из БД и поблочно передает эти данные клиентскому приложению, далее на клиенте СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации и т. д. Фактически, FS-модель предполагает автономную работу программного обеспечения ИС на разных машинах в сети. Компоненты ИС взаимодействуют только за счет наличия общего хранилища данных. Безусловно, таким хранилищем должна быть хорошо спроектированная БД под управлением СУБД, поддерживающей FS-модель, например, СУБД Informix SE. Такого рода СУБД нельзя считать «истинным сервером».

Модель архитектуры файлового сервера

При использовании FS-модели копия СУБД создается для каждого инициированного пользователем сеанса работы с СУБД, которая выполняется на том же процессоре, что и пользовательский процесс.

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

К недостаткам архитектуры «файл-сервер» можно отнести:

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

· ограниченное множество команд манипулирования данными, фактически это только файловые команды;

· низкая производительность (зависит от производительности сети, сервера, клиента);

· плохая возможность подключения новых клиентов;

· отсутствие развитых средств защиты данных (только на уровне файловой системы).

К несомненным достоинствам следует отнести

· высокую эффективность работы с небольшими объемами данных в однопользовательском режиме.

· удобство централизованного управления доступом;

· низкая стоимость разработки;

· высокая скорость разработки;

· невысокая стоимость обновления и изменения ПО.

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

Модель удаленного доступа к данным, RDA ( Remote Data Access , RDA )

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

Клиент заметно «похудел» по сравнению с FS-моделью, зато значительно расширились функции сервера, сократился сетевой трафик, а самое главное достоинство модели RDA: появился язык SQL с расширенным множеством команд определения данных и манипулирования данными, который унифицировал интерфейс клиент-сервер.

Модель архитектуры удаленного доступа к данным

Достоинства RDA-модели:

· перенос Business Logic на клиента существенно разгружает сервер БД, сводя к минимуму общее число процессов в операционной системе;

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

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

Недостатки RDA-модели:

· по-прежнему высокий сетевой трафик, особенно при большом количестве клиентов и их интенсивной работе в интерактивном режиме;

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

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

Модель сервера БД (иногда называют активный сервер)

Модель сервера (Data Base Server, DBS) - концепция, в соответствии с которой прикладной компонент (бизнес-логика) частично или полностью располагается на сервере базы данных (рис.4). Бизнес-логика реализована в виде хранимых программных единиц (ПрЕ), триггеров, пользовательских типов данных, которые хранятся в БД, а управляются сервером. В базе данных также накапливаются данные и формируется база метаданных (БМД). Клиентское приложение обращается к серверу с командой запуска ПрЕ, а сервер при необходимости выполняет её и фиксирует изменения в БД. Сервер возвращает результат запроса клиенту либо для вывода на периферийное устройство, либо для выполнения части бизнес-логики, которая расположена на клиенте. При таком способе распределения обработки данных сетевой трафик резко уменьшается.

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

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

DBS-модель поддерживает большинство современных СУБД: Oracle, Sybase, Ingres, Informix, MS SQL Server, хотя функциональные возможности у них разные.

Достоинства DBS-модели:

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

· снижение сетевого трафика за счет возможностей удаленного вызова процедур;

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

Недостатки:

Функции сервера:

1. Осуществляет мониторинг событий, связанных с описанными триггерами;

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

3. Обеспечивает исполнение внутренней программы каждого триггера;

4. Запускает хранимые процедуры по запросам пользователей;

5. Запускает хранимые процедуры из триггеров;

6. Возвращает требуемые данные клиенту;

7. Обеспечивает все функции СУБД: доступ к данным, контроль и поддержка целостности данных в БД, контроль доступа, обеспечение корректной работы всех пользователей с единой БД.

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

Сервер приложений

Сервер приложений (Application server , AS ) - разновидность многоуровневой архитектуры «клиент-сервер», основанный на схеме «клиент - сервер приложений».

В данной модели вводится дополнительный промежуточный уровень между клиентом и сервером. Этот промежуточный уровень содержит один или несколько серверов приложений. Отсюда и идентичное название - «модель сервера приложений» AS (Application Server).

В этой модели все компоненты ИС делятся между тремя исполнителями.

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

Модель сервера приложений

Серверы приложений исполняют наиболее общие правила бизнеса, поддерживают доменную среду, обеспечивают обмен сообщениями между компонентами приложений. Прикладные функции сервера приложений оформлены как отдельные службы или сервисы (Service). Служба предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. В архитектуре ИС серверов приложений может быть несколько, и каждый из них предоставляет определенный набор сервисов. Любая программа, которая пользуется ими, рассматривается как клиент сервера приложений AC (Application Client). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. АС обращается с запросом к конкретному сервису, а не к AS. Запросы выстраиваются в очередь к AS-процессу, который передает их для обработки конкретной службе согласно установленным приоритетам.

Серверы БД в этой модели занимаются исключительно функциями СУБД.

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

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

Достоинства AS-модели:

· повышение производительности за счет разгрузки сервера;

· удешевление эксплуатации ИС;

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

· улучшение свойств переносимости и масштабируемости ИС за счет использования стандартных языков программирования, например С, С++, Borland Pascal, Small Talk, Java, для реализации большей части бизнес-логики.

· клиентское ПО не нуждается в администрировании;

· конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

· высокая безопасность;

· высокая надежность;

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

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

Недостатки:

· растет сложность серверной части и, как следствие, затраты на администрирование и обслуживание;

· более высокая сложность создания приложений;

· сложнее в разворачивании и администрировании;

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

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

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

Лекция 2

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

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

Рассмотрим определение "архитектуры информационной системы", которое дают различные источники:

· Архитектура – это организационная структура системы.

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

· Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы.

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

· Архитектура программы или компьютерной системы – это структура системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними.

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

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

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

Под архитектурой программных систем будем понимать совокупность решений относительно:

· организации программной системы;

· выбора структурных элементов, составляющих систему и их интерфейсов;

· поведения этих элементов во взаимодействии с другими элементами;

· объединение этих элементов в подсистемы;

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

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

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

Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем необходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспособна развиваться и удовлетворять растущим потребностям пользователей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие.

Рассмотрим классификацию программных систем по их архитектуре:

· Централизованная архитектура;

· Архитектура "файл-сервер";

· Двухзвенная архитектура "клиент-сервер";

· Многозвенная архитектура "клиент-сервер";

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

· Архитектура Веб-приложений;

· Сервис-ориентированная архитектура.

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

Местоположение БД определяет так называемую архитектуру базы данных , и базы данных разделяются на:

· локальные;

· удаленные.

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

Расположение БД в значительной степени влияет на разработку приложения, обрабатывающего содержащиеся в этой базе данные.

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

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

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

Архитектура «файл-сервер» обычно применяется в сетях с небольшим количеством пользователей, для ее реализации подходят персональные СУБД, например, Рагаdох или dBasе. Достоинствами этой архитектуры являются простота реализации, а также то, что приложение фактически разрабатывается в расчете на одного пользователя и не зависит от того, на каком компьютере в сети оно устанавливается.

Достоинства такой архитектуры:

· многопользовательский режим работы с данными;

· удобство централизованного управления доступом;

· низкая стоимость разработки;

· высокая скорость разработки;

· невысокая стоимость обновления и изменения ПО.

Однако архитектура «файл-сервер» имеет и существенные недостатки.

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

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

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

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

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

Сервер – это сама СУБД. Он поддерживает все основные функции СУБД: определение данных, обработку данных, защиту данных, поддержание целостности данных и т.д.

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

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

1. Снижение нагрузки на сеть, поскольку теперь в ней циркулирует только нужная информация.

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

3. Уменьшение сложности клиентских приложений за счет отсутствия в них кода, связанного с контролем БД и разграничением доступа к ней.

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

· неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;

· администрирование данной системы требует квалифицированного профессионала;

· высокая стоимость оборудования;

· бизнес логика приложений осталась в клиентском ПО.

Для реализации архитектуры «клиент-сервер» обычно используются многопользовательские СУБД, например, Oracle или Мicrosoft SQL Server. Подобные СУБД также называют промышленными, так как они позволяют создать информационную систему организации или предприятия с большим числом пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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