Файл: Модель клиент-сервер (применение технологии «клиент-сервер» при проектировании).pdf

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

2 ИСПОЛЬЗОВАНИЕ ТЕХНОЛОГИИ «КЛИЕНТ-СЕРВЕР» В ВЕБ-ПРИЛОЖЕНИЯХ

2.1 Основные понятия

Веб-приложение – это «прикладное программное обеспечение, логика которого распределена между сервером и клиентом, а обмен информацией происходит по сети» [1]. При этом пользовательский интерфейс реализован на клиентской части, а серверная часть получает и обрабатывает запросы от клиента, выполняет вычисления, формирует веб-страницу и отправляет ее клиенту по протоколу HTTP [2]. Такие приложения обладают рядом особенностей, влияющих на их функционирование и разработку [3]:

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

Рассмотрим самые распространенные архитектуры веб-приложениях [4]:

1. Генерация HTML-страниц на стороне сервера - самая распространенная на данный момент архитектура. Заключается в том, что сервер генерирует HTML-контент и отправляет его клиенту как полноценную HTML-страницу (Приложение А).

2. Генерация HTML-контента посредством AJAX – является развитием архитектуры первого типа. Отличие состоит в том, что страница, отображаемая в браузере, состоит из функционально независимых блоков, данные в них грузятся AJAX-запросом с сервера: либо полноценным HTML-элементом; либо в виде JSON, и уже с помощью JavaScript преобразуются в контент страницы. На рисунке 8 показана схема веб-приложения.

Рисунок 8. Сферы ответственности баз данных, сервера и клиента

3. Одностраничное приложение (Single Page Application) – веб-приложение, использующее единственный HTML-документ как оболочку для всех веб-страниц и организующий взаимодействие с пользователем через динамически подгружаемые HTML и CSS, JavaScript. Данная архитектура является развитием архитектуры предыдущего типа, и доведение ее до полноценного уровня самостоятельного JavaScript приложения путем переноса бизнес-логики на клиентскую сторону. На рисунке 9 показано, как бизнес-логика и генерация HTML-кода переносятся с сервера на клиентскую сторону.

Рисунок 9. Сферы ответственности баз данных, сервера и клиента (SPA)

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

2.2 Применение веб-приложений

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

Традиционные веб-приложения реализуют лишь малую часть функций на стороне клиента и размещают все возможности навигации, обработки запросов и обновления на сервере. Соответственно, каждая выполняемая пользователем новая операция должна преобразовываться в веб-запрос, что влечет за собой полную перезагрузку страницы в браузере конечного пользователя. Такой подход обычно применяется в классических платформах MVC (модель-представление-контроллер), где каждый новый запрос соответствует новому действию контроллера, который, в свою очередь, работает с моделью и возвращает представление. Отдельные операции на конкретной странице могут быть оптимизированы с использованием функций AJAX (асинхронный JavaScript и XML), однако общая архитектура приложения использует множество различных представлений MVC и конечных точек URL-адресов.

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

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

2.3 Структура веб-приложения

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

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

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

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

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

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

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

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

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

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

Общепринятая организация логики приложения по слоям показана на рисунке 10.

Рисунок 10. Структура типового веб-приложения

Бэкэнд и фронэнд термины в программной инженерии, которые различают согласно принципу разделения ответственности между внешним представлением и внутренней реализацией соответственно [2].

Фронтенд это все, что браузер может читать, выводить на экран и запускать. То есть это HTML, CSS и JavaScript. HTML (HyperText Markup Language) сообщает браузеру, каково содержание страницы, например, «заголовок», «параграф», «список», «элемент списка». CSS (Cascading Style Sheets) при этом, сообщает браузеру, как отображать элементы, например, «после первого параграфа отступ в 20 пикселей» или «весь текст в элементе body должен быть темно-серым и написан шрифтом Verdana». JavaScript сообщает браузеру, как реагировать на некоторые взаимодействия, используя легкий язык программирования.

Бэкенд это все, что работает на сервере, то есть не в браузере или на компьютере, подсоединенном к Интернет, который отвечает на сообщения от других компьютеров. Для бэкенда можно использовать любые инструменты, доступные на сервере. Это означает, что можно использовать любой универсальный язык программирования: Ruby, PHP, Python, Java, JavaScript, Node и системы управления базами данных, такие как MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

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

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

3.1 Многоуровневый «клиент-сервер»

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