Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

Согласно данным аналитиков, количество используемых в настоящее время компьютеров превысило отметку в 2,5 млрд. По оценкам, ежегодное количество компьютеров в мире увеличивается на 12%, из них 85% соединены в информационно-вычислительные сети, начиная от локальных сетей в офисах до глобальных сетей типа Интернет. Мировая тенденция к объединению компьютеров в сети вызвана такими причинами, как скоростное получение и передача информации непосредственно на рабочем месте из любой точки земного шара. Применение на практике таких больших потенциальных возможностей, какие несут в себе информационно-вычислительные сети, значительно улучшает производственные процессы [12].

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

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

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

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

Для достижения этих целей решались следующие задачи:

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

Объектом исследования является локальная технология «клиент-сервер».

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

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

Работа состоит из введения, заключения, трех глав и списка использованных источников.

1 АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Общие сведения

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

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

Архитектура программы или компьютерной системы – это «структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними» [22].

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

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

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

Под архитектурой программных систем будем понимать совокупность решений относительно:

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

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

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

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

Законодателями стандартов в этой области выступают такие международные организации, как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java – JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и другие [11].

Рассмотрим классификацию программных систем по их архитектуре (рисунок 1):

Рисунок 1. Классификация программных систем по архитектуре

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

Далее подробно рассмотрим особенности каждой архитектуры.

Централизованная архитектура вычислительных систем была распространена в 70-х и 80-х годах и реализовывалась на базе мейнфреймов (например, IBM-360/370 или их отечественных аналогов серии ЕС ЭВМ), либо на базе мини-ЭВМ (например, PDP-11 или их отечественного аналога СМ-4). Характерная особенность такой архитектуры – полная «неинтеллектуальность» терминалов. Их работой управляет хост-ЭВМ (рисунок 2) [10].

Рисунок 2. Достоинства и недостатки централизованной архитектуры

Использование такой архитектуры является оправданным, если хост-ЭВМ очень дорогая, например, супер-ЭВМ.

Классическое представление централизованной архитектуры показано на рисунке 3.

Рисунок 3. Классическое представление централизованной архитектуры

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

1.2 Архитектура «файл-сервер»

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

Классическое представление информационной системы в архитектуре «файл-сервер» представлено на рисунке 4.

Рисунок 4. Классическое представление архитектуры «файл-сервер»

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

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

Рисунок 5. Достоинства и недостатки архитектуры «файл-сервер»

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

1.3 Архитектура «клиент-сервер»

Клиент-сервер (Client-server) – вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемых серверами, и заказчиками услуг, называемых клиентами. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и программным обеспечением.

Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture). Под клиент-серверным приложением в этом случае понимается информационная система, основанная на использовании серверов баз данных. Схематически такую архитектуру можно представить, как показано на рисунке 6.

Рисунок 6. Классическое представление архитектуры «клиент-сервер»

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

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

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

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

Рисунок 7. Достоинства и недостатки архитектуры «клиент-сервер»

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

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].

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

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

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

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

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

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

Рисунок 12. Преимущества и недостатки многозвенной архитектуры

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

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

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

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

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

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

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

3.2 Применение технологии «клиент-сервер» при проектировании распределенных систем

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

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

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

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

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

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

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

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

Рисунок 15. Архитектура распределенных систем с репликацией

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

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

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

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

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

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

3.3 Применение технологии «клиент-сервер» при проектировании Веб-приложений

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

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

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

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Веб-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Веб-страниц и наполнение Веб перестало быть чисто статическим.

Интерфейс ISAPI является функцией Microsoft Internet Information Server. Приложения ISAPI это динамически загружаемые библиотеки (DLL), которые выполняются в адресном пространстве веб-сервера. Другие веб-серверы через некоторое время также имеют возможность запускать приложения, реализованные в виде библиотек. В случае веб-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). Довольно популярный веб-сервер Apache также имеет возможность запускать веб-приложения, реализованные в виде библиотек; эти библиотеки называются Apache DSO (динамические общие объекты).

Естественно, что при использовании как CGI, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачу генерации HTML-кода, позволил получить доступ к компонентам и использовать базы данных. Этот интерфейс является объектной моделью active Server Pages (ASP) на основе фильтра ISAPI.

Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Веб-странице присутствуют фрагменты кода, который интерпретируется Веб-сервером и вместо которого пользователь получает результат выполнения этих фрагментов кода. Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер. Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Веб-приложения и Веб-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Веб-приложений.

В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP – Wireless Access Protocol) и соответствующие языки разметки (WML – Wireless Markup Language, СHTML – Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Схематически такую архитектуру (в трехзвенном варианте) можно представить, как показано на рисунке 17 [14].

Рисунок 17. Архитектура Веб-приложений

Другим способом поддержки различных типов клиентов является создание «разумных» серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET. Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, чтоб се ростомер объема используемых данных щи числа посетитьеёлейбл Веб-сайтов возрастают из требования ка надежности, производительности из масштабируемости Веб-приложений. Следующим этапом эволюции подогбаных приложений усталость отделеньице бизнес-логики, реализованной во Веб-приложении, ад нередко из сервисов обработки данных щи реализации транзакциякаций опт егоза интерфейса. В эстомп случаем во самом Веб-приложении обычность осотадесться такт называемая презентационная частью, ад бизнес-логика, обработка даннаных из реализация транзакций переносятся вэ серверный приложений во видео биозанес-объектов. В зависимости опт типаж сервера приложений подобные бизнес-объекты моргнуть бытьё выполняющимися самостоятельно COM-серверами, CORBA-серверами, ща также объектами COM+, выполняющимися юс помощью служба компонентов Windows 2000, иглица объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений, поддерживающим спецификаадциан ю J2EE (Java 2 Enterprise Edition). В качественно механизма доступа як данным подобные объектный могутный использоваться OLE DB, ODBC, JDBC (это зависит опт теогония, каик реализованный бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Обобщая вышесказанное можно выделить основные особенности веб-архитектуры (рисунок 18):

Рисунок 18. Особенности Веб-архитектуры

Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа «предприятие-клиент» (B2C – business-to-consumer). Не менее важными становятся и задачи интеграции Веб-приложений c данными и приложениями партнеров с целью реализации схемы «предприятие-предприятие» (B2B – business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Адам, Фримен jQuery для профессионалов / Фримен Адам. - М.: Диалектика / Вильямс, 2017. - 580 c.
Брюс, А. Тейт Ruby on Rails. Быстрая веб-разработка / Брюс А. Тейт, Курт Ниббс. - М.: БХВ-Петербург, 2017. - 224 c.
Изучаем Node.js. - М.: Питер, 2019. - 400 c.
Когаловский, М.Р. Перспективные технологии информационных систем / М.Р. Когаловский. - М.: Книга по Требованию, 2016. - 286 c.
Марк, Дэйв iOS 5 SDK. Разработка приложений для iPhone, iPad и iPod touch / Дэйв Марк, Джек Наттинг, Джефф Ламарш. - М.: Вильямс, 2015. - 672 c.
Нейгел, Кристиан C# 5.0 и платформа .NET 4.5 для профессионалов / Кристиан Нейгел и др. - М.: Вильямс, 2016. - 943 c.
Ник, Рендольф Visual Studio 2010 для профессионалов / Рендольф Ник. - М.: Диалектика / Вильямс, 2015. - 632 c.
Нильсен, Я. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств / Я. Нильсен. - М.: Эксмо, 2017. - 454 c.
Османи, Эдди Разработка Backbone.js приложений / Эдди Османи. - М.: Питер, 2017. - 510 c.
Рассел, Джесси Громыко, Ольга Николаевна / Джесси Рассел. - М.: VSD, 2019. - 450 c.
Рассел, Джесси Нидерландская Википедия / Джесси Рассел. - М.: VSD, 2016. - 646 c.
Ромашов, Виктор CMS Drupal. Система управления содержимым сайта / Виктор Ромашов. - М.: Питер, 2016. - 519 c.
Самков, Г. А. jQuery. Сборник рецептов / Г.А. Самков. - М.: БХВ-Петербург, 2019. - 416 c.
Севостьянов, Иван Поисковая оптимизация. Практическое руководство по продвижению сайта в Интернете / Иван Севостьянов. - М.: Питер, 2015. - 272 c.
Спикльмайр, Стив Zope. Разработка Web-приложений и управление контентом / Стив Спикльмайр. - М.: ДМК Пресс, 2016. - 512 c.
Уэндеелл Одометр. Официальное руководство Ciscdo под подготовке к сертификационным экзаменам Cisco CCENOT, 2011, - 324 с.
Фленов, М. Web-серверный глазами хакера (+ CD-ROM) / Михабил Фленов. - М.: БаХВал-Петербургер, 2014. - 1566 c.
Фролмов, А.В. Локальные свезти персональных компьютеров. Работка с сервером / А.В. Фролов, Г.В. Фролов. - М.: Диалогизм-Мифи, 2015. - 1655 c.
Фролов А.В. Бразды данных в Интернете. Праклтическое руководство под созданию Web-приложений с базабми данных / А.В. Фролов, Г.В. Фролмов. - М.: Microsoft Press. Руссткая Редакция, 2000. - 1401 c.
Хестер, Н. Создание Web-сайтов в Microsoft Expression Web / Н. Хестер. - М.: Книга по Требованию, 2015. - 254 c.
Шишмарев, В.Ю. : учеб. пособие для студ. сред. проф. образования / В.Ю. Шишмарев. – М.: Академия, 2017. – 304 с.