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

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

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

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

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

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

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

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

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

2. "Толстый" сервер:
# усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;
# производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;
# программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
# получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обращение к БД осуществляется на языке SQL, который стал стандартом для реляционных БД. Поэтому сервер БД называют SQL-сервером, который поддерживается всеми реляционными СУБД: Oracle, Informix, MS SQL, ADABAS D, InterBase, SyBase и др.

Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.). При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер (Open Data Base Connectivity), который обеспечивает возможность пересылки и преобразования данных из глобальной БД в структуру БД клиентского приложения.

Представление

данных пользователя Приложение База данных

Централизованная

Архитектура

«Файл-сервер»

Двухуровневая

архитектура

«клиент-сервер»

Трехуровневая

Архитектура

«клиент-сервер»

Многоуровневая

Архитектура

«клиент-сервер»

Рис.2. Варианты клиент-серверной архитектуры КЭИС

Трехуровневая клиент-серверная архитектура позволяет помещать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс (Application Program Interface) устанавливается связь клиентских рабочих станций. Клиентская часть приложения вызывает необходимые функции сервера приложения, называемые «сервисами». Прикладные программы в свою очередь обращаются к серверу БД с помощью SQL запросов. Такая организация позволяет повысить производительность и эффективность КЭИС за счет:

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

параллельности в работе сервера приложений и сервера БД, причем сервер приложений может быть менее мощным по сравнению с сервером БД;

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

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

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

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

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

4.3. Многоуровневые системы клиент-сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Д

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

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

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

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

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

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

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

Государстве и обществе на основе перспективных информационных технологий ; – процессы формирования... 2. Информационные технологии конечного пользователя. Технологии открытых систем. сетевые информационные технологии 2.1. Информационные технологии конечного...

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

Ключевым отличием архитектуры клиент-сервер от архитектуры файл-сервер является абстрагирование от внутреннего представления данных (физической схемы данных). При такой архитектуре клиентские программы манипулируют данными на уровне логической схемы. Для реализации архитектуры клиент-сервер обычно используют многопользовательские СУБД, например, Oracle или Microsoft SQL Server.

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

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

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

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

К достоинствам этой архитектуры относятся:

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

· обеспечение целостности данных.

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

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

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

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

· Слабая защита данных от взлома, в особенности от недобросовестных пользователей системы.

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

· Необходимость использовать мощные ПК на клиентских местах.

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

Преимущества

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

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

· Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

Недостатки

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

· Поддержка работы данной системы требует отдельного специалиста - системного администратора.

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

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

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

Частные случаи многоуровневой архитектуры:

В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

Обзор архитектуры

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

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

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

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

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

Достоинства

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

· масштабируемость

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

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

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

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

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

Недостатки

Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

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

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

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

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

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

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

Архитектура компьютерной системы развилась наряду со способностями аппаратных средств использовать запускаемые приложения. Самой простой (и самой ранней) из всех была «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: Ряды разделены на логические слои