Файл: Технология «клиент-сервер ».pdf

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

Разработчики и пользователи информационных систем, основанных на архитектуре «клиент-сервер», часто бывают неудовлетворены постоянно существующими сетевыми «накладными расходами», которые вытекают из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента^[26].

Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных баз данных. Как и в целом, для поддержки локального кэша базы данных программное обеспечение рабочей станции должно включать компонент управления базой данных-упрощенную версию сервера базы данных, которая, например, может не обеспечивать многопользовательский доступ. Отдельной проблемой является согласованность (слаженность) кэшей и общей базы данных. Существуют различные решения – от автоматической поддержки согласованности за счет средств базового управления базами данных, программного обеспечения до полного перекладывания этой задачи на прикладной уровень (рисунок 7)^[27].

Рисунок 7 – Достоинства и недостатки архитектуры «клиент-сервер»^[28]

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

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

---

2. ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ ТЕХНОЛОГИИ «КЛИЕНТ-СЕРВЕР»

Многоуровневая архитектура клиент-сервер (Multitier architecture) – разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура, предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных. Схематически такую архитектуру можно представить, как показано на рисунке 8^[31].

Рисунок 8 - Представление многоуровневой архитектуры «клиент-сервер»^[32]

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

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

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

---

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

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

Рисунок 9 – Преимущества и недостатки многозвенной архитектуры^[36]

Некоторые авторы (например, Мартин Фаулер) представляют многозвенную архитектуру (трехзвенную) в виде пяти уровней (рисунок 10)^[37]:

Рисунок 10 - Пять уровней многозвенной архитектуры «клиент-сервер»

Представление включает в себя всю информацию, непосредственно отображаемую пользователю: сгенерированные html-страницы, таблицы стилей, изображения^[38].

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

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

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

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

---

ГЛАВА 3. ПРИМЕНЕНИЕ ТЕХНОЛОГИИ «КЛИЕНТ-СЕРВЕР» ПРИ ПРОЕКТИРОВАНИИ ИНФОРМАЦИОННЫХ СИСТЕМ

Проектирование распределенных систем

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

Рисунок 11 - Архитектура распределенных систем^[41]

Более 95 % данных, используемых в управлении предприятием могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы^[42].

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

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

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

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

Еще одно преимущество такой схемы эксплуатации и архитектуры системы является возможность персональной ответственности за сохранность данных. Поскольку данные, доступные на конкретном рабочем месте, находятся только на этом компьютере, использование шифрования и персональных аппаратных ключей исключает доступ к данным третьих лиц, в том числе ИТ-администраторов^[44].

---

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

Рисунок 12 - Архитектура распределенных систем с репликацией^[45]

Распределенные системы с элементами удаленного исполнения

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

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

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

Рисунок 13 - Архитектура распределенных систем с удаленным исполнением^[46]

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

Проектирование Веб-приложений

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

Изначально World Wide Web (WWW) представлялась ее создателям как «пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой». Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная^[47].

Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство^[48].

---