сервер приложений трехуровневая модель
Модель сервера приложений(трехуровневая модель).
Эта модель является расширением 2-хуровневой модели, в ней вводится дополнительный промежуточный уровень – сервер-приложений(рис. 2.6.3.3.1.).
Рис. 2.6.3.3.1. Модель сервера приложений.
В этой модели компоненты приложения делятся между 3-мя источниками:
1. клиент – обеспечивает функции ввода и изображения данных, запроса процедур.
2. сервер приложений поддерживает функции клиентов в плане общих прикладных функций, а так же поддерживает каталоги с данными и обеспечивает обмен сообщениями и поддержку запросов.
1) Создание и ведение БД.
3) Восстановление БД при сбоях и т.д.
4) Функции хранилища данных.
Эта модель обладает наибольшей гибкостью.
Корпоративные ИС на базе интернет-технологии.
В таких ИС (рис. 2.6.4.1.) обычно осуществляется объединение корпоративных ЛВС с Web-сервером. Отличительной особенностью таких систем считается:
1. Возможность хранения и обработки не только структурированных, символьных и числовых данных, а также хранение документов, видео, цифровой и звуковой информации.
2. Регламентированность информации о состоянии объекта(корпорации) для внешних пользователей через Интернет.
Обычно защищенная сеть INTRANET подключается к открытой сети INTERNET с помощью специального WEB-сервера (брандмауэра) устанавливающего определенные ограничения на передаваемую в INTERNET информацию.
Географически распределенные ИС(глобальные ИС).
Любой из узлов способен:
1. выполнять запросы пользователей, требующих доступа к локально сохраненным данным.
2. обрабатывать данные, сохраненные на др. объектах-компьютерах сети(сайтах, узлах).
При этом на каждом сайте могут распологаться как глобальные, так и локальные приложения. Локальные приложения не требуют доступа к данным на других сайтах, глобальные – требуют. ФБД также может содержать локальную базу данных и часть глобальной БД.
Пользователи взаимодействуют с РБД через свои приложения.
Трехуровневая клиент-серверная архитектура
Для решения этих проблем и была предложена так называемая 3-х уровневая архитектура клиент-сервер (рис.1.9). Основным ее отличием от архитектуры 2.5 является физическоеразделение программ, отвечающих за хранение данных (СУБД) от обрабатывающих эти данные программ (сервер приложения (СП). Такое разделение программных компонент позволяет оптимизировать нагрузки как на сетевое, так и на вычислительное оборудование комплекса.
 |
| Рисунок 1.9 – Схема трехуровневой архитектуры ИС |
Компоненты трехуровневой архитектуры, с точки зрения программного обеспечения реализуют определенные серверы БД, web-серверы и браузеры. Место любого из этих компонентов может занять программное обеспечение любого производителя. Модель сервера приложений показана на рис.1.10.
Ниже представлено описание взаимодействия компонентов трехуровневой архитектуры клиент-серверного приложения. Сервер БД представлен MySQL-сервером; сервер приложений технологиями: ADO.NET, ASP.NET и web-сервером IIS; роль клиента выполняет любой web-браузер.
Схематично работу системы можно представить в виде последовательности: Браузер клиента1-> Сервер IIS2-> Исполняющая среда ASP.NET 2.03-> Провайдер данных ADO.NET 2.04-> Сервер MySQL5-> Провайдер данных ADO.NET 2.06-> Исполняющая среда ASP.NET 2.07-> Сервер IIS8-> Браузер клиента.
Более детально функционирование системы происходит следующим образом.
1 — браузер клиента отправляет HTTP-запрос;
2 — на стороне сервера служба Web Internet Information Server (web-сервер IIS) определяет тип запрашиваемого ресурса, и для случая запроса *.aspx (расширение файлов страниц ASP.NET) загружает соответствующее ему (запросу) расширение Internet Server Aplication Programming Interface (ISAPI). Для страниц aspx это расширение isapi_aspnet.dll. IIS также осуществляет идентификацию и авторизацию пользователя от которого поступил запрос. В свою очередь расширение isapi_aspnet.dll загружает фабрику обработчиков ASP.NET. Далее, фабрика обработчиков создает объектную модель запрашиваемой страницы и обрабатывает действия пользователя.
3 — в ходе генерации ответа приложению ASP.NET может потребоваться обращение к БД, в этом случае используя библиотеки классов провайдера данных ADO.NET 2.0, выполняющая среда обращается к серверу БД;
4 — провайдер данных ADO.NET 2.0 передает запрос на операцию с БД серверу MySQL;
 |
| Рис.1.10 – Модель сервера приложений трехуровневой ИС |
5 — сервер MySQL осуществляет обработку запроса, выполняя соответствующие операции с БД;
6 — провайдер данных ADO.NET 2.0 передает результаты запроса объекту страницы;
7 — объект страницы с учетом полученных данных осуществляет визуализацию (рендеринг) графического интерфейса страницы и направляет результаты в выходной поток;
8 — сервер IIS отправляет содержимое сгенерированной страницы клиентскому браузеру.
Преимуществом трехуровневой архитектуры является:
1. Меньшая нагрузка на клиентское приложение («Тонкий клиент»).
3. Сервер приложения ИС может быть запущен в одном или нескольких экземплярах на одном или нескольких компьютерах, что позволяет использовать вычислительные мощности организации столь эффективно и безопасно как этого пожелает администратор ИС.
4. Дешевый трафик между сервером приложений и СУБД. Трафик между сервером приложений и СУБД может быть большим, однако это всегда трафик локальной сети, а их пропускная способность достаточно велика и дешева. В крайнем случае, всегда можно запустить сервер приложений и СУБД на одной машине, что автоматически сведет сетевой трафик к нулю.
5. Снижение нагрузки на сервер данных по сравнению с 2.5-слойной схемой, а значит и повышение скорости работы системы в целом.
6. Дешевле наращивать функциональность и обновлять ПО.
К недостаткам архитектуры можно отнести более высокие расходы на администрирование и обслуживание серверной части.
Масштабируемость систем выполненных по трехуровневой архитектуре очень высокая. Одна и та же система может работать как на одном отдельно стоящем компьютере, выполняя на нем программы СУБД, сервера приложений и клиентской части, так и в сети, состоящей из сотен и тысяч машин.
Сервер приложений. Трехуровневая модель
Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 2.6.
Рис. 2.6. Архитектура трехуровневой модели
Такая архитектура предполагает, что на клиенте располагаются: функции ввода и отображения данных, включая графический пользовательский интерфейс, локальные редакторы, коммуникационные функции, которые обеспечивают доступ клиенту в локальную или глобальную сеть.
Серверы баз данных в этой модели занимаются исключительно функциями управления информационными ресурсами БД: обеспечивают функции создания и ведения БД, поддерживают целостность БД, осуществляют функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и так далее.
Промежуточному уровню, который может содержать один или несколько серверов приложений, выделяются общие не загружаемые функции для клиентов: наиболее общие прикладные функции клиента, функции, поддерживающие сетевую доменную операционную среду, каталоги с данными, функции, обеспечивающие обмен сообщениями и поддержку запросов.
Преимущества трехуровневой модели наиболее заметны в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных.
Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет
2.4.2. Сервер приложений. Трехуровневая модель
Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 2.6.
Рис. 2.6. Архитектура трехуровневой модели
Такая архитектура предполагает, что на клиенте располагаются: функции ввода и отображения данных, включая графический пользовательский интерфейс, локальные редакторы, коммуникационные функции, которые обеспечивают доступ клиенту в локальную или глобальную сеть.
Серверы баз данных в этой модели занимаются исключительно функциями управления информационными ресурсами БД: обеспечивают функции создания и ведения БД, поддерживают целостность БД, осуществляют функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и так далее.
Промежуточному уровню, который может содержать один или несколько серверов приложений, выделяются общие не загружаемые функции для клиентов: наиболее общие прикладные функции клиента, функции, поддерживающие сетевую доменную операционную среду, каталоги с данными, функции, обеспечивающие обмен сообщениями и поддержку запросов.
Преимущества трехуровневой модели наиболее заметны в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных.
3. Концепции проектирования бд
3.1. Жизненный цикл бд
Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы.
ЖЦБД включает в себя следующие основные этапы (рис. 3.1):
планирование разработки базы данных;
определение требований к системе;
сбор и анализ требований пользователей;
проектирование базы данных:
концептуальное проектирование базы данных;
логическое проектирование базы данных;
физическое проектирование базы данных;
проектирование пользовательского интерфейса;
эксплуатация и сопровождение:
анализ функционирования и поддержка исходного варианта БД;
адаптация, модернизация и поддержка переработанных вариантов.
Рис. 3.1. Жизненный цикл БД
3.1.1. Планирование разработки базы данных
Содержание данного этапа — разработка стратегического плана, в процессе которой осуществляется предварительное планирование конкретной системы управления базами данных.
Планирование разработки базы данных состоит в определении трех основных компонентов: объема работ, ресурсов и стоимости проекта.
Важной частью разработки стратегического плана является проверка осуществимости проекта, состоящая из нескольких частей.
Первая часть — проверка технологической осуществимости. Она состоит в выяснении вопроса, существует ли оборудование и программное обеспечение, удовлетворяющее информационным потребностям фирмы.
Вторая часть — проверка операционной осуществимости — выяснение наличия экспертов и персонала, необходимых для работы БД.
Третья часть — проверка экономической целесообразности осуществления проекта. При исследовании этой проблемы весьма важно дать оценку ряду факторов, в том числе и таким:
целесообразность совместного использования данных разными отделами;
величина риска, связанного с реализацией системы базы данных;
ожидаемая выгода от внедрения подлежащих созданию приложений;
время окупаемости внедренной БД;
влияние системы управления БД на реализацию долговременных планов организации.
Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.
Распределенная обработка данных
Двухуровневые модели
Двухуровневая модель фактически является результатом распределения пяти указанных функций между двумя процессами, которые выполняются на двух платформах: на клиенте и на сервере. В чистом виде почти никакая модель не существует, однако рассмотрим наиболее характерные особенности каждой двухуровневой модели.
Модель удаленного управления данными. Модель файлового сервера
Распределение функций в этой модели представлено на рис. 10.4.
В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база мета-данных, находится на клиенте.
Достоинства этой модели в том, что мы уже имеем разделение монопольного приложения на два взаимодействующих процесса. При этом сервер ( серверный процесс ) может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на клиенте.
Каков алгоритм выполнения запроса клиента?
Запрос клиента формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента, далее на клиенте СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации и т. д.
Перекачка информации с сервера на клиент производится до тех пор, пока не будет получен ответ на запрос клиента.
Модель удаленного доступа к данным
В модели удаленного доступа (Remote Data Access, RDA ) база данных хранится на сервере. На сервере же находится ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 10.5.
Преимущества данной модели:
Модель сервера баз данных
Для того чтобы избавиться от недостатков модели удаленного доступа, должны быть соблюдены следующие условия:
В этой модели бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур — специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу, которые требуются клиенту либо для вывода на экран, либо для выполнения части бизнес-логики, которая расположена на клиенте. Трафик обмена информацией между клиентом и сервером резко уменьшается.
Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД.
Термин «триггер» взят из электроники и семантически очень точно характеризует механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер. Каждый триггер представляет собой также некоторую программу, которая выполняется над базой данных. Триггеры могут вызывать хранимые процедуры.
Механизм использования триггеров предполагает, что при срабатывании одного триггера могут возникнуть события, которые вызовут срабатывание других триггеров. Этот мощный инструмент требует тонкого и согласованного применения, чтобы не получился бесконечный цикл срабатывания триггеров.
И хранимые процедуры, и триггеры хранятся в словаре БД, они могут быть использованы несколькими клиентами, что существенно уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях.
Недостатком данной модели является очень большая загрузка сервера. Действительно, сервер обслуживает множество клиентов и выполняет следующие функции:
Если мы переложили на сервер большую часть бизнес-логики приложений, то требования к клиентам в этой модели резко уменьшаются. Иногда такую модель называют моделью с «тонким клиентом», в отличие от предыдущих моделей, где на клиента возлагались гораздо более серьезные задачи. Эти модели называются моделями с » толстым клиентом «.
Для разгрузки сервера была предложена трехуровневая модель.
Модель сервера приложений
Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 10.7. Этот промежуточный уровень содержит один или несколько серверов приложений.
В этой модели компоненты приложения делятся между тремя исполнителями: