27.Основные архитектуры информационных систем.

В любом приложении м. выделить след. компоненты:1. компонент представления (presentation), реализующий функции первой группы;

2. прикладной компонент (business application), поддерживающий функции второй группы; 3. компонент доступа к инф-м ресурсам (resource access) или менеджер ресурсов (resource manager), поддерживающий ф-и 3й группы.

В арх-ре "хост/терминал" функции всех 3 групп совмещены в одном коде, который выполняется на компьютере-сервере (хосте). Компьютер-клиент в данной арх-ре отсутствует в принципе, а ввод и отобр-е д-х производятся через терминал или компьютер в режиме эмуляции терминала.

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

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

В архитектуре "клиент/сервер" функции приложения распределены между двумя (или более) компьютерами. Выделяются три модели:

1. Модель доступа к удаленным данным (Remote Data Access - RDA);

2. Модель сервера базы данных (DataBase Server - DBS);

3. Модель сервера приложений (Application Server - AS).

В RDA-модели коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте. Клиент поддерживает ф-и ввода и отображения данных, прикладные функции ("толстый" клиент).

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

Осн. преим-во RDA-модели: широкий выбор средств быстрой разработки приложений различных фирм.

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

В DBS-модели процесс, выполняемый на компьютере-клиенте, огранич-ся ф-ми представления ("тонкий" клиент), а прикладные ф-и реализованы в хранимых процедурах (stored procedure), которые также называют компилируемыми резидентными процедурами, или процедурами БД. Они хранятся непосред-но в БД и выполняются на компьютере-сервере БД, где функционирует и компонент, упр-й доступом к данным, то есть ядро СУБД.

DBS-модель реализована в некоторых реляционных СУБД (Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования ядра СУБД.

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

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

; Децентрализация приложений требует существенного разнообразия вариантов взаимодействия клиента и сервера.

На практике часто используются смешанные модели, когда поддержка целостности БД и некоторые простейшие прикладные ф-и поддерживаются хранимыми процедурами (DBS-модель), а более сложные ф-и реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).

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

Осн. эл-том принятой в AS-модели 3-звенной схемы является сервер приложения. Их мб несколько, и каждый их них предоставляет определенный набор услуг. Детали реализации прикладных ф-й в сервере приложений полностью скрыты от клиента приложения.

AS-модель в наибольшей степени отражает сильные стороны технологии "клиент/сервер":

• Четкое разграничение логических компонентов приложения.

• Возм-ть баланса загрузки между несколькими серверами.

• Значит. сниж-е трафика м/д клиентом и сервером приложений, дающее возможность работы по медленным линиям связи.

• Выс. уровень защиты данных.

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

• Упрощение процесса обновления ПО.

Фунд-е различие м/д моделями арх-ры "клиент/сервер" закл. в след: RDA- и DBS-модели опираются на 2-звенную схему разделения функций. В RDA-модели прикладные ф-и приданы программе-клиенту, в DBS-модели ответственность за их выполн-е берет на себя ядро СУБД. В 1м случае прикл-й компонент сливается с компонентом представления, во втором - интегрируется в компонент доступа к инф-м ресурсам. В AS-модели реализована классич-я 3-звенная схема разделения ф-й, где прикладной компонент выделен как важнейший элемент приложения, для его определения используются универсальные механизмы многозадачной ОС, и стандартизованы интерфейсы с двумя другими компонентами.

Результаты анализа различных архитектур:

Архитектура "хост/терминал" явл. оптимальным реш-ем при построении небольших инф-х систем, в которых не требуется граф-й интерфейс с пользов-м. В случае необход-ти использ-я граф интерф можно ориентир-ся на RDA-модель архитектуры "клиент/сервер". AS-модель архитектуры "клиент/сервер" является лучшим вариантом для создания больших инф-х систем, а также в случае использ-я низкоскоростных каналов связи.