Файл: Конспект лекций профессиональная образовательная программа.docx

1.1.1. Модель доступа к удаленным данным

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



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

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

К недостаткам можно отнести:

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

1.1.2. Модель сервера управления данными

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


Рис. 1.3 - Модель сервера управления данными

---

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

Главным преимуществом модели сервера управления данными перед моделью доступа к удаленным данным является снижение объема информации, передаваемой по сети, так как выборка требуемых информационных элементов из файлов выполняется не на рабочих станциях, а на сервере. Преимуществом RDA-модели является также широкий выбор средств быстрой разработки приложений (RAD) различных фирм. Кроме того, в настоящее время существует множество инструментальных средств, обеспечивающих быстрое создание приложений с развитым интерфейсом, работающих с SQL-ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Подавляющее большинство этих средств разработки на языках четвертого поколения (включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления. Это обеспечивает унификацию и широкий выбор средств разработки приложений.

В то же время RDA-модель имеет ряд недостатков и ограничений.

1. 
   Отсутствие четкого разграничения между компонентом представления и прикладным компонентом, что затрудняет дальнейшее совершенствование ИС, архитектура которой построена на основе данной модели.
   
2. 
   Очень большая загрузка сети. Приложение является нераспределенным, и вся его логика локализована на компьютере-клиенте, поэтому взаимодействие его с сервером посредством SQL-запросов приводит к передаче по сети данных большого объема, возможно, избыточных. Как только число клиентов возрастает, сеть становится узким местом, ограничивая быстродействие всей информационной системы.
   
3. 
   Сложность ведения больших проектов. Очевидно, что если различные по своей природе функции (функции представления и чисто прикладные функции) смешаны в одной и той же программе, написанной на языке 4GL, то при необходимости изменения прикладных функций приходится переписывать всю программу целиком. При коллективной работе над проектом, как правило, каждому разработчику поручается реализация отдельных прикладных функций, что делает невозможным контроль за их взаимной непротиворечивостью. Каждому из разработчиков приходится программировать интерфейс с пользователем, что ставит под вопрос единый стиль интерфейса и его целостность.
   
4. 
   Сложность обновления программного обеспечения, т.к. его замену необходимо производить одновременно на всех компьютерах-клиентах.
   
5. 
   Низкий уровень безопасности, т.к. реализация разграничения доступа по функциям возможна только на стороне клиента, а на стороне сервера разграничение выполняется только по таблицам базы данных, что снижает защищенность.
   

---

1.1.3. Модель комплексного сервера

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


Рис. 1.5 - Модель комплексного сервера
Модель комплексного сервера по сравнению с моделью сервера управления данными является более технологичной. Она строится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции и функции доступа к данным выполняются сервером. DBS-модель реализована в некоторых реляционных СУБД (Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования ядра СУБД. Прикладные функции могут быть реализованы в отдельных программах или в хранимых процедурах, которые называют также процедурами базы данных. Эти процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере-сервере, где функционирует и компонент, управляющий доступом к данным, т. е. ядро СУБД. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL.

Преимущества DBS-модели очевидны:

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

Однако есть и недостатки:

1. 
   Средства, используемые для написания хранимых процедур, строго говоря, не являются языками программирования в полном смысле слова. Это разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональным возможностям с языками третьего поколения (C или Pascal) и тем более четвертого поколения. Они встроены в конкретные СУБД, и, естественно, рамки их использования ограничены. Следовательно, система, в которой прикладной компонент реализован при помощи хранимых процедур, не является мобильной относительно СУБД. В большинстве СУБД отсутствуют возможности отладки и тестирования хранимых процедур, что превращает последние в весьма опасный механизм. Во многих реализациях процедуры являются интерпретируемыми, что делает их выполнение более медленным.
   
2. 
   Не обеспечивается требуемой эффективности использования вычислительных ресурсов. Объективные ограничения в ядре СУБД не позволяют пока организовать в его рамках эффективный баланс загрузки, миграцию процедур на другие компьютеры-серверы БД и реализовать другие полезные функции. Попытки разработчиков СУБД предусмотреть в своих системах эти возможности (распределенные хранимые процедуры, запросы с приоритетами и т. д.) пока не позволяют добиться желаемого эффекта.
   
3. 
   Децентрализация приложений (один из ключевых факторов современных информационных технологий) требует существенного разнообразия вариантов взаимодействия клиента и сервера. При реализации прикладной системы могут понадобиться такие механизмы взаимодействия, как хранимые очереди, асинхронные вызовы и т. д., которые в DBS-модели не поддерживаются.
   

---

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

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

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


Рис.1.6 - Модель трехзвенной архитектуры «клиент-сервер»
Основным элементом принятой в AS-модели трехзвенной схемы является сервер приложения. В его рамках реализовано несколько прикладных функций, каждая из которых оформлена как служба (service) и предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться. Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения (Application Client - AC). Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. AC обращается с запросом к конкретной службе, но не к AS, то есть серверы приложений обезличены и служат лишь своего рода "рамкой" для оформления служб, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от АС, выстраиваются в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами.

---

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

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

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

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

1. 
   Четкое разграничение логических компонентов приложения.
   
2. 
   Возможность баланса загрузки между несколькими серверами.
   
3. 
   Значительное снижение трафика между клиентом и сервером приложений, дающее возможность работы по медленным линиям связи.
   
4. 
   Высокий уровень защиты данных, т.к. они являются "спрятанными" за сервисами приложения, в которые можно встроить проверку полномочий клиента.
   
5. 
   Возможность использования в качестве клиентской части приложения стандартного браузера.
   
6. 
   Упрощение процесса обновления ПО.
   

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

---