Наиболее распространенной архитектурой ис для бизнес приложений является

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

Что такое архитектура информационной системы

Начнем с определения: согласно Федеральному закону РФ от 27.06.2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации», информационная система – это совокупность содержащейся в базах данных информации и обеспечивающих её обработку информационных технологий и технических средств. Проще говоря, под информационной системой (ИС) обычно мы понимаем базу данных и интерфейс работы с ней, который позволяет решать специализированные бизнес-задачи, удовлетворяя потребности пользователя. Причем слово интерфейс здесь имеет общее значение как средство взаимодействия чего-то с чем-то, например, интеракция пользователя с программным обеспечением ПО реализуется через GUI и набор программных интерфейсов (API, Application Programming Interface).

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

• Слой представления – клиентская часть с графическим интерфейсом пользователя (GUI, Graphical User Interface), которая выполняет роль терминала – средства представления данных и отправки команд. Часто этот слой называют frontend.
• Слой бизнес-логики, где происходит обработка команд, полученных от клиента и выполняются основные вычисления. Чаще всего это реализуется в виде серверного приложения (backend). Здесь же располагается система управления базой данных (СУБД) как надстройка над базой данной (БД), которая позволяет обратиться к данным и манипулировать ими, о чем мы писали здесь.
• Слой доступа к данным, т.е. сама БД как хранилище данных в структурированном виде, что в конечном итоге на низком уровне сводится к файлам с записанными данными.

Такая послойная модель компонентного строения ИС получила название 3-хслойной архитектуры и сегодня реализуется везде. Однако, реализация этих 3-х слоев может быть выполнена по-разному. Если все компоненты всех 3-х слоев находятся на одном устройстве (компьютер, мобильный телефон), такая архитектура называется настольной (desktop). Например, локальный (не облачный) текстовый редактор, калькулятор. А если компоненты 3-х слоев ИС распределены по нескольким устройствам, ее архитектура называется распределенной (distributed). Именно такая архитектура сегодня встречается в большинстве современных ИС, что мы и рассмотрим далее.

Основные виды распределенных архитектур

Поскольку компоненты распределенной системы распределены по разным устройствам (узлам), им необходимо средство взаимодействия друг с другом, т.е. сеть передачи информации. Передача данных по сети выполняется по правилам сетевых протоколов, которые регламентируют вид и формат передаваемых данных. Лучше всего эту идею иллюстрирует 7-ми уровневая модель OSI (Open Systems Interconnection) — модель стека сетевых протоколов OSI/ISO. Она показывает, как разные сетевые устройства могут взаимодействовать друг с другом и определяет различные уровни взаимодействия систем, каждый из которых выполняет при этом специализированные функции. О том, что представляет собой модель OSI, мы поговорим в следующий раз, а пока вернемся к видам распределенной архитектуры.

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

• Файл-серверная – самая примитивная распределенная архитектура, когда слои представления и бизнес-логики находятся на клиенте, а также там реализуется часть вычислений, т.е. операторов по обработке данных. Сервер отвечает только за хранение и управление файлами. Это простое и дешевое с точки зрения реализации решение подходит только ИС, небольших по количеству пользователей, имеет низкую производительность и предполагает передачу по сети огромного объема данных.
• Клиент-серверная, которая делится на 2 подвида:
  • двузвенная – своего рода развитие файл-серверной версии. Она также обеспечивает многопользовательскую работу с данными, но имеет более высокую надежность, т.к. теперь на клиенте находится лишь слой представления и часть слоя бизнес-логики, такая как операторы обращения к СУБД. А другая часть манипулирования с данными, зашитая в СУБД, например, хранимые процедуры (объект БД в виде набора SQL-инструкций, компилируется лишь однажды и хранится на сервере), непосредственное выполнение запросов, обработка транзакций, а также само хранение файлов с данными и управление ими – реализуется на мощном сервере. Это снижает требования к клиентскому узлу, но не устраняет необходимость передачи большого объема данных по сети. Клиент становится тоньше по сравнению с файл-серверной моделью, но это все еще «толстый клиент».
  • трехзвенная – устраняет недостатки двухзвенной архитектуры, располагая каждый из слоев на отдельном узле. Теперь на клиенте находится только пользовательский интерфейс со средствами вывода данных и ввода команд. По сути, клиент превращается в терминал и называется «тонкий клиент». За выполнение вычислений и формирование запросов к СУБД отвечает сервер приложений, а слой доступа к данным в виде СУБД и БД находится на отдельном сервере данных. Таким образом, трехзвенная архитектура устраняет почти все недостатки файл-серверной и клиент-серверной на 2-х звеньях ценой увеличения расходов на администрирование и разработку серверных частей.

Можно графически изобразить развертывание компонентов всех 3-х слоев трехзвенной архитектуры по узлам в виде соответствующей UML-диаграммы (deployment).

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

А детально познакомиться с основами архитектуры и интеграции информационных систем вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Основы архитектуры и интеграции информационных систем
• Разработка ТЗ на информационную систему по ГОСТ и SRS
• UML для бизнес-аналитика: основы ООП и разработка моделей

Виды архитектуры информационной системы

Любая информационная система (ИС) включает в себя три компонента:

• Управление данными;
• Бизнес-логику;
• Пользовательский интерфейс.

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

Однако, эти три компонента в разных ИС взаимодействуют друг с другом различными способами.

Существуют следующие виды архитектур ИС:

• Локальная;
• Файл-серверная;
• Клиент-серверная;
• Трехслойная.

Локальные информационные системы

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

Файл-серверная архитектура

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

«Архитектура информационной системы» 👇

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

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

Клиент-серверная архитектура

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

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

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

Трехуровневая архитектура

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

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

Презентацию к данной лекции Вы можете скачать здесь.

5.1. Архитектура информационных систем

5.1.1. Общие сведения

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

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

Рассмотрим определение «архитектуры информационной системы», которое дают различные источники:

• Архитектура – это организационная структура системы [3].
• Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы [4].
• Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы [5].
• Архитектура – это набор значимых решений по поводу организации системы программного обеспечения, набор структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры, который направляет эту организацию – элементы и их интерфейсы, взаимодействия и компоновку [6].
• Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними [7].
• Архитектура – это структура организации и связанное с ней поведение системы [8]. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы.
• Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы [9]. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.

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

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

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

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

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

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

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

• Централизованная архитектура;
• Архитектура «файл-сервер»;
• Двухзвенная архитектура «клиент-сервер»;
• Многозвенная архитектура «клиент-сервер»;
• Архитектура распределенных систем;
• Архитектура Веб-приложений;
• Сервис-ориентированная архитектура.

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

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

5.1.2. Централизованная архитектура

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

Достоинства такой архитектуры [11, 12]:

• пользователи совместно используют дорогие ресурсы ЭВМ и дорогие периферийные устройства;
• централизация ресурсов и оборудования облегчает обслуживание и эксплуатацию вычислительной системы;
• отсутствует необходимость администрирования рабочих мест пользователей;

Главным недостатком для пользователя является то, что он полностью зависит от администратора хост-ЭВМ. Пользователь не может настроить рабочую среду под свои потребности – все используемое программное обеспечение является коллективным.

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

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

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

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

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

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

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

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

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

Конечно, основным достоинством данной архитектуры является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows Server. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД.

Достоинства такой архитектуры [12, 13, 14]:

• многопользовательский режим работы с данными;
• удобство централизованного управления доступом;
• низкая стоимость разработки;
• высокая скорость разработки;
• невысокая стоимость обновления и изменения ПО.

Недостатки [12, 13, 14]:

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

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

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

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

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

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

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

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

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

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

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

• Сервер производит компиляцию полученного оператора.
• Далее (если компиляция завершилась успешно) происходит выполнение оператора.

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

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

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

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

Недостатки [12, 15]:

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

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

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

Также данный вид архитектуры называют архитектурой с «толстым» клиентом.

Содержание:

ВВЕДЕНИЕ

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

• база данных;

• процесс;

• подсистема;

• вычислительный узел;

• библиотека;

• и др.

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

Многие объединяют термины «архитектура» и «структура» в один. Но это не одно и то же, хотя структура приложения напрямую зависит от архитектуры. Когда мы произносим «архитектура приложений», то речь идет в широком смысле о компонентах будущей системы приложения. Однако каждый архитектурный компонент может быть организован и представлен разными решениями. Эти решения и образуют структуру приложения. То есть структура более точно описывает инструменты и модули будущего приложения.

Архитектура приложений

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

Каждое архитектурное решение должно удовлетворять несколько заинтересованных лиц:

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

• администратора приложения — в его интересах, чтобы у приложения была понятная система управления;

• СЕО-специалиста и маркетолога — в их интересах, чтобы приложение обладало уникальными функциями и было конкурентоспособным;

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

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

Архитектура приложений: выбор и виды

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

• заинтересованных лицах: заказчиках, пользователях, разработчиках и др.;

• миссии приложения — отсюда вытекают требования к приложению;

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

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

• архитектура «клиент-сервер»;

• монолитная архитектура;

• микропроцессорная архитектура;

• событийная;

• структурированная;

• многослойная;

• трехуровневая;

• сервис-ориентированная;

• поиск-ориентированная;

• неявная;

• и др.

Архитектура приложений: распространенные виды

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

Многослойная архитектура

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

Многослойная архитектура разделяет программу на следующие слои:

• слой представления — отвечает за интерфейс пользователя;

• слой бизнес-логики — отвечает за функционал и логику приложения и не отвечает за интерфейс;

• слой передачи данных — отвечает за работу с базами данных и обработку информации.

Каждый элемент в приложении «проходит» через все слои. Такая архитектура считается:

• простой в реализации;

• абстрактной;

• защищенной за счет изолированности каждого слоя;

• легко управляемой и масштабируемой.

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

Многоуровневая архитектура приложений

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

• одноуровневая,

• двухуровневая,

• трехуровневая.

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

Двухуровневый вид имеет еще одно название — архитектура «клиент-сервер». Приложения на такой архитектуре задействуют два места для обработки приложения:

• клиент — отвечает за обработку интерфейса, логики приложения и передачу информации;

• сервер — отвечает за работу хранилищ и баз данных, а также за обработку информации.

Трехуровневый вид архитектуры подразумевает наличие трех точек для работы приложения:

• клиент,

• сервер для обработки,

• базы данных для хранения.

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

Микросервисная архитектура приложений 

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

Такая архитектура часто встречается в разработке, так как она обладает рядом неоспоримых преимуществ:

• изолированность каждого отдельного компонента;

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

• удобно масштабировать и внедрять обновления;

• и др.

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

Заключение

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