Основы проектирования корпоративных систем - Сергей Зыков

Исторически первым методом организации клиент-серверного взаимодействия была RPC. Эта архитектура значима и сегодня. На довольно низком уровне можно обеспечить распределение нагрузки. Некоторые компоненты могут располагаться на клиенте. Если ЛВС вычислительно неоднородна, то взаимодействие на уровне процедурных сервисов позволяет скрыть неоднородность сети. При этом снижается значимость аппаратной совместимости. Часть парка аппаратного обеспечения может быть заменена без критического влияния на важные системы. Принцип открытых систем сглаживает подобные неровности инкапсуляцией функциональности на прикладном уровне процедур приложений. Если говорить о SQL-сервере, то функциональное разделение производится следующим образом. СУБД работает на стороне сервера, на стороне клиента организуется лишь инициирование запросов к SQL-серверу. Вся работа по формированию запросов, обработке данных, организации транзакционного многопользовательского взаимодействия осуществляется на стороне сервера. Ряд запросов носит типовой характер. Результат этих запросов стоит кешировать в ОЗУ на сервере. Таким образом возникает возможность хранения кэша на выделенном сервере. Если клиент использует одни и те же запросы, стоит кешировать БД на локальной машине. Так можно моделировать работу сервера на клиенте и осуществлять ряд операций по обработке данных локально. В отличие от традиционной клиент-серверной архитектуры мы получаем распараллеливание и балансировку прикладных функций между клиентом и сервером. Прежде чем обсудить трехзвенную архитектуру, поговорим об особенности архитектуры сервера баз данных.

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

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

Вернемся к вопросу о балансировке нагрузки между клиентом и сервером. Речь идет о выделении третьего уровня прикладной логики. Верхний уровень, связанный с логикой работы приложения, расщепляется на два. Трехуровневая архитектура включает в себя презентационную логику (PL), бизнес-логику (BL) и логику доступа к ресурсам (AL). BL можно размещать как на сервере, так и на клиенте, а также выделить на отдельный сервер, тогда появляется понятие сервера приложений. Тонкий клиент – легкий клиент с презентационной логикой, например браузер. Толстый клиент (remote data access, RDA) объединяет бизнес-логику и презентационную логику. Сервер приложений можно выделить в отдельный программный уровень.

Под толстым клиентом (RDA) понимается объединение на клиентской части логики, связанной с презентацией, и бизнес-логики. Только логика доступа к ресурсам оставлена на сервере (рис. 6.4).

Рис. 6.4. Модель трехуровневой архитектуры клиент – сервер: толстый клиент

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

Рис. 6.5. Модель трехуровневой архитектуры клиент – сервер: тонкий клиент

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

Рис. 6.6. Модель трехуровневой архитектуры клиент – сервер: сервер приложений

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

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

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

При использовании тонкого клиента вся бизнес-логика, которая была сосредоточена на каждом из сотен тысяч клиентов, переносится на сервер и централизованно управляется там. Она взаимодействует с данными и SQL-серверами. Клиент снабжается только пользовательским интерфейсом. Администрирование и централизованная миграция производятся на сервере, поэтому изменения с точки зрения сроков и стоимости происходят более эффективно. Бизнес-логика может быть расположена на одном и том же сервере с БД, а может быть перенесена на один или несколько серверов. Коррективы в таких системах можно вносить как на нижнем уровне, так и на более высоком. Например, в семействе Oracle Applications на нижнем уровне расположен сервер базы данных Oracle Server, а на более высоком уровне существует Application Server, на котором и располагаются все компоненты, выполняющие прикладные задачи. Это ERP-системы Oracle Applications или Oracle Business Suit, которые осуществляют прикладную логику: учет, планирование и управление основными видами корпоративных ресурсов.