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

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

В последнее время многоуровневая ( multitier ) архитектура пользуется все большей популярностью, поскольку имеет массу преимуществ перед файл-серверными или клиент-серверными приложениями. Такая архитектура в различных публикациях также называется многозвенной, или распределенной архитектурой. Суть многоуровневой архитектуры в том, что помимо сервера БД и приложений-клиентов дополнительно присутствует еще один или несколько серверов приложений. Сервер приложений является промежуточным уровнем, обеспечивающим организацию взаимодействия клиентов и сервера БД . Сервер приложений также называют брокером данных ( broker — посредник). Чаще всего используют трехуровневую модель. Прежде, чем мы двинемся дальше, давайте разберемся, что же такое уровень. Имеется три основных уровня:

• Уровень данных. Этот уровень отвечает за хранение данных. Как правило, для этого уровня выделяется отдельный ПК, на котором устанавливают один из SQL -серверов, например, InterBase . Клиентские ПК непосредственно не имеют никакой связи с этим уровнем.
• Бизнес-уровень. Этот уровень предназначен для получения данных с уровня данных, выполнения окончательной проверки данных, и служит посредником между клиентами и данными. Как правило, сервера приложений находятся именно на этом уровне.
• Уровень представления данных. Этот уровень известен так же, как уровень графического интерфейса пользователя. На этом уровне полученные данные отображаются в таких компонентах вывода данных, как DBGrid , DBEdit , DBMemo и проч. Разумеется, этот уровень находится на клиентских ПК.

Взгляните на рисунок:

На рисунке представлены три уровня архитектуры: так называемый, «тонкий» клиент ( thin-client ), сервер приложений и сервер данных. На ПК сервера БД вместе с данными расположен один из SQL -серверов. Как видите, на клиентском ПК, помимо компонентов доступа к данным, располагается только компонент связи с сервером приложений, а довольно громоздкие механизмы доступа к данным отсутствуют. Из-за этого клиентское приложение и называется «тонким» клиентом. Такой подход не только облегчает распространение приложений, но и позволяет в качестве клиентских ПК использовать дешевые, неприхотливые компьютеры. На сервере приложений вы можете видеть область, обозначенную как » Интерфейс IAppServer «. Этот интерфейс обеспечивается специальным удаленным модулем данных, о котором дальше мы поговорим подробней. Интерфейс IAppServer используют компоненты-провайдеры TDataSetProvider на стороне сервера приложений, и компоненты TClientDataSet на стороне клиента.

При небольшом количестве клиентов ничто не мешает нам отказаться от использования SQL -сервера, расположив данные на самом сервере приложений, и используя к ним обычный локальный доступ через механизм BDE , ADO и т.п. При этом можно использовать обычные таблицы Paradox или MS Access , например. Такой подход удобней, чем файл -серверная архитектура , поскольку позволяет не только «облегчить» пользовательское приложение , но и обеспечивает безопасность данных . Ведь пользователи не будут иметь прямого доступа к самим данным, обмен информацией будет происходить через посредника, как на рисунке ниже:

Несмотря на кажущуюся сложность архитектуры, организовать такую модель достаточно просто. Delphi для этого предлагает технологию DataSnap (в старых версиях Delphi эта технология называлась MIDAS — Multi-tier Distributed Applications Services — Серверы многозвенных распределенных приложений ). Благодаря этой технологии, вы сможете создать простой сервер приложений буквально за минуту, не введя ни строчки кода.

Преимущества многоуровневых моделей

• Централизованная бизнес-логика. Как мы уже знаем, бизнес-логикой называют некоторые правила обработки данных. Например, удаляя запись из одной таблицы, требуется удалить связанные с ней записи других таблиц. В обычных файл-серверных или клиент-серверных приложениях, часть бизнес-логики ложилась на клиентское приложение. При необходимости изменения каких-то правил, приходилось переделывать клиентское приложение, затем тратить усилия на его распространение на клиентские ПК. Теперь же эта бизнес-логика хранится на уровне сервера приложений, и при ее изменении клиенты сразу получают возможность работать по новым правилам.
• Архитектура «тонкого» клиента.Как известно, для получения данных из БД приложения используют один из механизмов доступа к данным — BDE , ADO , ODBC , IBX , dbExpress и т.п. Все это приводит к тому, что на ПК каждого клиента приходится устанавливать и настраивать соответствующие драйверы, а это сильно усложняет процесс распространения приложения. В многозвенной архитектуре механизмы доступа к данным располагаются на сервере приложений. Только там нужно устанавливать эти драйверы (например, BDE ). Клиентские же машины не нуждаются в них, за что и называются «тонкими».
• Модель «портфеля» (briefcase model).Модель «портфеля» подразумевает возможность отложенной обработки данных. Представьте, что вам в выходные дни требуется проделать какую-то работу с данными. При использовании файл-серверной или клиент-серверной модели, вам для этой работы придется прибыть в офис, иначе вы не сможете получить доступа к данным. В многоуровневой модели вы можете сохранить на переносном ПК все необходимые вам данные в виде локального файла. Дома вы сможете загрузить этот файл, и провести необходимую работу с данными. Затем, прибыв в офис, вы сможете перенести эти изменения в реальную базу данных.
• Снижение трафика сети. За счет возможности отложенной обработки данных значительно снижается нагрузка на сеть.

Сервер приложений

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

Delphi поддерживает следующие технологии удаленного доступа:

• DCOM ( Distributed Component Object Model — Распределенная компонентная модель объектов) Модель рассчитана на локальную сеть и позволяет использовать объекты, расположенные на другом ПК. Если клиентское приложение работает под управлением Windows 95 (что маловероятно в настоящее время), то придется также установить поддержку DCOM95 , остальные версии Windows в этом не нуждаются. Поскольку модель является «родной» для ОС Windows , использовать ее довольно просто. Вероятно, наиболее популярная модель на сегодняшний день.
• Сокеты — позволяют использовать сеть по протоколу TCP/IP . Эта модель, пожалуй, дает наиболее быстрое соединение, однако имеется ряд замечаний. Во-первых, программисту приходится прилагать дополнительные усилия для организации связи и слежением за возможными ошибками. Во-вторых, чтобы можно было загрузить сервер приложений, сначала на компьютере с этим сервером нужно загрузить утилиту SCKTSRVR.EXE. Эта утилита устанавливается вместе с Delphi и по умолчанию находится в папке C:PROGRAM FILESBORLANDDELPHIBIN. При загрузке программы ее ярлык появляется в трее (в правом нижнем углу экрана), и с этого момента клиентские ПК смогут соединяться с этим сервером. Обычно запуск этой утилиты прописывают на сервере в автозагрузке.
• MTS ( Microsoft Transaction Server — Сервер транзакций Microsoft ) — основана на DCOM и имеет некоторые дополнительные возможности.
• CORBA ( Common Object Request Broker Architecture — Общедоступная архитектура брокеров при запросе объектов).
• SOAP ( Simple Object Access Protocol — Простой протокол доступа к объекту.)

Загрузите Delphi и начните новый проект. Главная форма нам совсем не понадобится, назовите ее fMain , в свойстве Caption напишите » Сервер приложений «, уменьшите ее размер (например, Height =120, W >Main , а проекту в целом — MyNewServer . Основой сервера является удаленный модуль данных, который обеспечивает связь сервера с клиентами, а также является контейнером для размещения компонентов, вроде обычного Data Module. Delphi позволяет использовать следующие удаленные модули:

• Remote Data Module — используется для серверов DCOM , сокетов и OLEnterprise ;
• Transactional Data Module — используется для сервера MTS ;
• CORBA Data Module — для сервера CORBA ;
• SOAP Data Module — для сервера SOAP ;
• WebSnap Data Module — использует Web -службы и Web -броузер в качестве сервера.

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

Важно! Следует знать, что обмен данными между сервером приложений и «тонкими» клиентами обеспечивается динамической библиотекой Midas.dll, которая должна быть зарегистрирована на компьютере сервера приложений.

Мы будем использовать технологию DCOM , поэтому выберите команду меню File -> New -> Other, чтобы открыть окно депозитария Delphi . Перейдите на вкладку Multitier и выберите Remote Data Module . Откроется окно мастера создания удаленного модуля данных:

В первом поле » Co >MyRDM . Следующие два поля требуют более детального изучения.

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

• Internal — при такой модели сервер COM не сможет создаваться из внешних приложений. Используется редко, в основном, когда нужно управлять доступом с помощью промежуточного уровня прокси.
• Single Instance — при выборе этой модели для каждого клиентского соединения будет создан свой экземпляр сервера.
• Multiple Instance — в этой модели все клиентские соединения используют единый экземпляр сервера.

В этом поле оставляем способ по умолчанию Multiple Instance.

Поле Threading Model предлагает выбрать модель потоков, что позволяет распределять соединения по отдельным потокам без необходимости применения дополнительного кода. Допустимы следующие модели:

• Single (Одиночная) — для клиентов выделяется один поток, все клиенты работают последовательно. Выбор такой модели может оказаться неудачным в многопользовательской среде, и используется редко.
• Apartment (Раздельная) — для каждого клиента создается собственный поток. В сочетании с Multiple Instance этот способ дает самые высокие результаты и наиболее часто применяется.
• Free (Свободная) — один экземпляр модуля данных может одновременно отвечать на несколько запросов клиентов, используя разные потоки.
• Both (Оба) — объединяет модели Free и Apartment .
• Neutral (Нейтральный) — разные клиенты могут одновременно вызвать удаленный модуль данных из нескольких потоков, при этом модель COM следит, чтобы не было конфликта вызовов. Однако может возникнуть конфликт потоков, который отслеживается только в версии COM+ . При отсутствии этой версии нужно использовать модель Apartment .

В этом поле оставляем модель по умолчанию Apartment.

Краткий обзор 10 популярных архитектурных шаблонов приложений

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

Что такое архитектурный шаблон?

По материалам Википедии,

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

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

1. Многоуровневый шаблон

2. Клиент-серверный шаблон

4. Каналы и фильтры

5. Шаблон посредника

6. Одноранговый шаблон

1. Многоуровневый шаблон

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

Чаще всего в общих информационных системах встречаются следующие 4 слоя:

· Слой представления (также известен как слой пользовательского интерфейса)

· Слой приложения (также известен как слой сервиса)

· Слой бизнес-логики (также известен как уровень предметной области)

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

Использование

· Общие десктопные приложения.

2. Клиент-серверный шаблон

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

Использование

· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).

3. Ведущий-ведомый

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

Использование

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

· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).

4. Каналы и фильтры

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

Использование

· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

· Рабочие процессы в биоинформатике.

5. Шаблон посредника

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

Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.

Использование

6. Одноранговый шаблон

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

Использование

· Проприетарные мультимедийные приложения (как тот же Spotify).

7. Шина событий

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

Использование

· Разработки на Android

8. Модель-представление-контроллер

Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:

1. модель — содержит ключевые данные и функционал;

2. представление — показывает информацию пользователю (можно задавать более одного представления);

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

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

Использование

· Архитектура WWW-приложений, написанных на основных языках программирования.

9. Доска

Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:

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

· источник знания — специализированные модули со своим собственным представлением;

· компоненты управления — выбирает, настраивает и исполняет модули.

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

Использование

· идентификация и отслеживание транспортных средств;

· определение структур белка;

· интерпретация сигналов Sonar.

10. Интерпретатор

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

Использование

· языки запросов к базе данных (SQL);

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

Сравнение архитектурных шаблонов

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

Многоуровневый шаблон

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

• Не универсален.
• В ряде ситуаций возможен пропуск некоторых слоев.

Клиент-серверный шаблон

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

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

Шаблон «Ведущий-ведомый»

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

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

Шаблон «Каналы и фильтры»

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

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

Шаблон «Посредник»

• Возможно динамическое изменение, добавление, удаление и перемещение объектов. Этот шаблон делает процесс распределения прозрачным для разработчика.

• Необходима стандартизация описаний служб.

Одноранговый шаблон

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

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

Шаблон «Шина событий»

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

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

Шаблон «Модель-представление-контроллер»

• Упрощает создание различных представлений одной и той же модели; их можно включить или отключить на этапе выполнения.

• Возрастает сложность алгоритма. Может привести ко многим ненужным корректировкам действий пользователей.

Шаблон «Доска»

• Легкое добавление новых приложений.
• Можно без труда расширять структуры пространства данных.

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

Шаблон «Интерпретатор»

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

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

Многоуровневая архитектура в проекте на Java (Часть 1)

В настоящее время в разработке ПО достаточно часто применяется многоуровневая архитектура или многослойная архитектура (n-tier architecture), в рамках которой компоненты проекта разделяются на уровни (или слои). Классическое приложение с многоуровневой архитектурой, чаще всего, состоит из 3 или 4 уровней, хотя их может быть и больше, учитывая возможность разделения некоторых уровней на подуровни. Одним из примеров многоуровневой архитектуры является предметно-ориентированное проектирование (Domain-driven Design, DDD), где основное внимание сконцентрировано на предметном уровне.

В проектах с многоуровневой архитектурой можно выделить четыре уровня (или слоя):

• Слой представления, с которым взаимодействует пользователь или клиентский сервис. Реализацией слоя представления может быть, например, графический пользовательский интерфейс или веб-страница.
• Сервисный слой, реализующий взаимодействие между слоями представления и бизнес-логики. Примерами реализаций сервисного слоя являются контроллеры, веб-сервисы и слушатели очередей сообщений.
• Слой бизнес-логики, в котором реализуется основная логика проекта. Компоненты, реализующие бизнес-логику, обрабатывают запросы, поступающие от компонентов сервисного слоя, а так же используют компоненты слоя доступа к данным для обращения к источникам данных.
• Слой доступа к данным — набор компонентов для доступа к хранимым данным. В качестве источников данных могут выступать различного рода базы данных, SOAP и REST-сервисы, файлы на файловой системе и т.д.

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

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

Допустим, у нас есть код, реализующий бизнес-логику приложения, который находится в контроллере. Что если нам требуется разработать SOAP-сервис, реализующий ту же функциональность? Мы можем скопировать существующий код в SOAP-сервис и внести в него изменения по мере необходимости. Будет ли ли такой подход работать? Да! Вызовет ли такой подход проблемы? Тоже да! В процессе жизненного цикла проекта требования к нему имеют свойство меняться, что ведёт к неизбежным изменениям и в коде. Но при таком подходе нам придётся изменить код и в контроллере, и в SOAP-сервисе, а также внести изменения в их тесты (вы же тестируете свой код?). Но граздо правильнее будет вынести общий код, реализующий бизнес-логику, в компонент слоя бизнес-логики. В этом случае в контроллере и SOAP-сервисе останется код, преобразующий запрос к общему виду, понятному компоненту бизнес-логики.

Очевидным фактом является то, что бизнес-логика — самая важная составляющая вашего проекта. И именно с проработки компонентов слоя бизнес-логики должна начинаться разработка проекта.

К слову сказать, очень хорошей практикой является применение UML, в данном конкретном случае — диаграммы классов. Из собственной практики помню случай, когда я решил для почти готового проекта составить диаграмму классов, результатом чего стал рефакторинг, уменьшивший количество кода примерно на 20%. Составление диаграммы классов на ранних этапах разработки позволяет уменьшить дублирование кода, сделать структуру классов и зависимости между ними более понятными.

В так полюбившейся мне книге Роберта Марина «Чистая архитектура» автор пропагандирует идею независимости (или минимизации зависимости) архитектуры приложения от внешних факторов: фреймворков, баз данных и прочих сторонних зависимостей. Это говорит не об отказе от использования этих зависимостей (вы же не будете разрабатывать собственный механизм трансляции HTTP-вызовов или хранения данных?), а о минимизации их влияния на архитектуру вашего проекта.

Разработка бизнес-логики

Давайте возьмём в качестве примера разработку блокнота, который пользователь может использовать для работы с заметками. Заметьте, я не указал, что это будет онлайн-сервис или настольное приложение. Для начала определимся с набором типов (классов и интерфейсов), которые нам понадобятся для нашего проекта. Класс-сущность, описывающий заметку — Note, компонент бизнес-логики, реализующий работу с заметками — NoteService, ещё нам потребуется компонент слоя доступа к данным — NoteRepository. Простая реализация NoteService — SimpleNoteService, использует NoteRepository для доступа к источнику данных. Диаграмма классов, описывающая текущую архитектуру, будет достаточно простая:

Теперь можно описать эти типы в коде, написать тесты для SimpleNoteService и реализовать этот класс.

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

Обзор архитектуры

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

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

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

Достоинства

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

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

Недостатки

Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

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