Меню
ГлавнаяWord

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

рис. 5.4 .


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

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

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

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

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

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


Рис. 5.5. Пять уровней многозвенной архитектуры "клиент-сервер"

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

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

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

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

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

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

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

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


Рис. 5.6.

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

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

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

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

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

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

План лекции

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, для реализации большей части бизнес-логики.

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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