ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 52
Скачиваний: 1
СОДЕРЖАНИЕ
Традиционные архитектуры информационных систем. Файл-серверная архитектура
Количество клиентов ограничено десятками.
1. Многопользовательский режим работы с данными;
· Клиентская программа работает с данными через запросы к серверному ПО.
· Базовые функции приложения разделены между клиентом и сервером.
· Полная поддержка многопользовательской работы
· Слабая защита данных от взлома, в особенности от недобросовестных пользователей системы.
· Высокая сложность администрирования и настройки рабочих мест пользователей системы.
· Необходимость использовать мощные ПК на клиентских местах.
§ 1 — браузер клиента отправляет HTTP-запрос;
Internet/Intranet – технологии
Архитектура на основе Internet/Intranet с мигрирующими программами
Для наших задач хватит достаточно вольной характеристики.
Распределенная система — это набор независимых вычислительных машин,
представляющийся их пользователям единой объединенной системой.
В этом определении оговариваются два момента.
Первый относится к аппаратуре: все машины автономны.
Характеристики распределенных систем:
Распределенная система организована в виде службы промежуточного уровня
1. Ссылки на объекты в распределенных системах в противоположность являются более комплексными:
1.1.Содержат информацию о размещении
2. Ссылки на распределенные объекты значительно больше (40 байт для Orbix)
Локальные вызовы требуют порядка пары сотен наносекунд
Запрос к объекту требует от 0.1 до 10 миллисекунд
2. Укрупнить выполняемые функции
Объекты в ОО языках находятся в виртуальной памяти от создания до уничтожения
2. Объекты могут не использоваться на протяжении долгого времени
Реализации распределенных объектов
1. Переносятся в память при активации
2. Удаляются из памяти при деактивации
Объекты могут иметь или не иметь состояние.
Объекты имеющие состояние должны сохранять его на постоянный носитель между:
2. Отражением на реляционные БД
В нераспределенных системах исполнение в основном последовательное, иногда
конкурентное в разных нитях процессов.
Запросы в распределенных системах имеют большую вероятность отказов
Клиенты обязаны проверять факт выполнения запросов сервером
1. Кто запрашивает выполнение операции?
2. Как мы можем удостовериться, что субъект является именно тем за кого он себя выдает?
3. Как мы примем решение предоставлять или нет субъекту право на выполнение сервиса?
4. Как мы можем неопровержимо доказать, что сервис был предоставлен?
Архитектура ИС
Ст.преподаватель
Кафедра ИСТ
Традиционные архитектуры информационных систем. Файл-серверная архитектура
- Появились локальные сети. Файлы начали передаваться по сети. Сначала были одноранговые сети - все компьютеры равноправны
Потом возникла идея хранения всех общедоступных файлов на выделенном компьютере в сети - файл-сервере
Файл-серверные приложения — приложения, схожие по своей структуре с локальными приложениями и использующие сетевой ресурс для хранения программы и данных. Функции сервера: хранения данных и кода программы. Функции клиента: обработка данных происходит исключительно на стороне клиента.Количество клиентов ограничено десятками.
Плюсы:
1. Многопользовательский режим работы с данными;
- Удобство централизованного управления доступом;
- Низкая стоимость разработки;
Минусы:
1. Низкая производительность;
2. Низкая надежность;
3. Слабые возможности расширения
Основные особенности:
· Клиентская программа работает с данными через запросы к серверному ПО.
· Базовые функции приложения разделены между клиентом и сервером.
Плюсы:
· Полная поддержка многопользовательской работы
· Гарантия целостности данных
Минусы:
· Бизнес логика приложений осталась в клиентском ПО. При любом изменении алгоритмов, надо обновлять пользовательское ПО на каждом клиенте.
· Высокие требования к пропускной способности коммуникационных каналов с сервером, что препятствует использование клиентских станций иначе как в локальной сети.
· Слабая защита данных от взлома, в особенности от недобросовестных пользователей системы.
· Высокая сложность администрирования и настройки рабочих мест пользователей системы.
· Необходимость использовать мощные ПК на клиентских местах.
· Высокая сложность разработки системы из-за необходимости выполнять бизнес-логику и обеспечивать пользовательский интерфейс в одной программе
Нетрудно заметить, что большинство недостатков классической или 2-х слойной архитектуры клиент-сервер проистекают от использования клиентской станции в качестве исполнителя бизнес-логики ИС. Поэтому очевидным шагом дальнейшей эволюции архитектур ИС явилась идея "тонкого клиента", то есть разбиения алгоритмов обработки данных на части связанные с выполнением бизнес-функций и связанные с отображением информации в удобном для человека представлении. При этом на клиентской машине оставляют лишь вторую часть, связанную с первичной проверкой и отображением информации, перенося всю реальную функциональность системы на серверную частьИспользование хранимых процедур и вычисление данных на стороне сервера сокращают трафик, увеличивают безопасность. Клиент все равно реализует часть бизнес- логики.
Как видно, такая организация системы весьма напоминает организацию первых унитарных систем с той лишь разницей, что на пользовательском месте стоит не терминал (с пресловутым зеленым экраном), а персональный компьютер, обеспечивающий ГИП, например, в последнее время в качестве клиентских программ часто применяют стандартные www-броузеры. Конечно, такой возврат к почти унитарным системам произошел уже на ином технологическом уровне. Обязательным стало использование СУБД со всеми их преимуществами. Программы для серверной части пишут, в основном, на специализированных языках, пользуясь механизмом хранимых процедур сервера БД Таким образом, на уровне логической организации, ИС в архитектуре клиент-сервер с тонким клиентом расщепляется на три слоя - слой данных, слой бизнес-функций (хранимые процедуры) и слой представления. К сожалению, обычно, в такой схеме построения ИС не удается написать всю бизнес-логику приложения на не предназначенных для этого встроенных языках СУБД. Поэтому, очень часто часть бизнес- функций реализуется в клиентской части систем, которая от этого неотвратимо "толстеет". Отчасти поэтому, отчасти потому, чтофизически такие ИС состоят из двух компонентов, эту архитектуру часто называют 2.5-слойный клиент-сервер В отличие от 2-х слойной архитектуры 2.5-слойная архитектура обычно не требует наличия высокоскоростных каналов связи между клиентской и серверной частями системы, так как по сети передаются уже готовые результаты вычислений - почти все вычисления производятся на серверной стороне. Существенно улучшается также и защита информации - пользователям даются права на доступ к функциям системы, а не на доступ к ее данным и т.д. Однако вместе с преимуществами унитарного подхода архитектура 2.5 перенимает и все его недостатки, как-то: ограниченную масштабируемость, зависимость от программной платформы, ограниченное использование сетевых вычислительных ресурсов. Кроме того программы для серверной части системы пишутся на встроенных в СУБД языках описания хранимых процедур, предназначенных для валидации данных и построения несложных отчетов, а вовсе не для написания ИС масштаба предприятия. Все это снижает быстродействие системы, повышает трудоемкость создания с модификации ИС и самым негативным образом сказывается на стоимости аппаратных средств, необходимых для ее функционирования Для решения этих проблем и была предложена так называемая 3-х слойная архитектура клиент-сервер. Основным ее отличием от архитектуры 2.5 является физическое разделение программ, отвечающих за хранение данных (СУБД) от программ эти данные обрабатывающих (сервер приложения (СП), application server (AS)). Такое разделение программных компонент позволяет оптимизировать нагрузки как на сетевое, так и на вычислительное оборудование комплекса Компоненты трѐхзвенной архитектуры, с точки зрения программного обеспечения реализуют определенные сервера БД, web-сервера и браузеры. Место любого из этих компонентов может занять программное обеспечение любого производителя. Ниже представлено описание взаимодействия компонентов трехуровневой архитектуры клиент- серверного приложения. Сервер БД представлен MySQL-сервером; сервер приложений технологиями: ADO.NET, ASP.NET и web-сервером IIS; роль клиента выполняет любой web-браузер Браузер клиента 1-> Сервер IIS 2-> Исполняющая среда ASP.NET 2.0 3-> Провайдер данных ADO.NET 2.0 4-> Сервер MySQL 5-> Провайдер данных ADO.NET 2.0 6-> Исполняющая среда ASP.NET 2.0 7-> Сервер IIS
8-> Браузер клиента
§ 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;
- § 5 — сервер MySQL осуществляет обработку запроса, выполняя соответствующие операции с БД ;
- § 6 — провайдер данных ADO.NET 2.0 передает результаты запроса объекту страницы;
- § 7 — объект страницы с учетом полученных данных осуществляет рендеринг графического интерфейса страницы и направляет результаты в выходной поток;
- § 8 — сервер IIS отправляет содержимое сгенерированной страницы клиентскому браузеру
Плюсы:
- 1. Тонкий клиент.
- 2. Между клиентской программой и сервером приложения передается лишь минимально необходимый поток данных - аргументы вызываемых функций и возвращаемые от них значения. Это теоретический предел эффективности
- использования линий связи, даже работа с ANSI-терминалами (не говоря уже об использование протокола http) требует большей нагрузки на сеть.
- 3. Сервер приложения ИС может быть запущен в одном или нескольких экземплярах на одном или нескольких компьютерах, что позволяет использовать вычислительные мощности организации столь эффективно и безопасно как этого пожелает администратор ИС.
- 4. Дешевый трафик между сервером приложений и СУБД. Трафик между сервером приложений и СУБД может быть большим, однако это всегда трафик локальной сети, а их пропускная способность достаточно велика и дешева. В крайнем случае, всегда можно запустить СП и СУБД на одной машине, что автоматически сведет сетевой трафик к нулю.
- 5. Снижение нагрузки на сервер данных по сравнению с 2.5-слойной схемой, а значит и повышение скорости работы системы в целом.
- 6. Дешевле наращивать функциональность и обновлять ПО
- Минусы:
- 1. Выше расходы на администрирование и обслуживание серверной части. Масштабируемость систем выполненных в 3-х слойной архитектуре впечатляет. Одна и та же система может работать как на одном отдельно стоящем компьютере, выполняя на нем программы СУБД, СП и клиентской части, так и в сети, состоящей из сотен и тысяч машин. Как уже было отмечено, единственным фактором, препятствующим бесконечной масштабируемости, является лишь требование ведения единой базы данных