СТАТЬЯ

16.05.03

Анализ вариантов архитектур и платформ для построения информационных систем

(Часть 1)

Содержание

• Введение
• 1. Анализ архитектуры
  • 1.1. Функции приложения
  • 1.2. Архитектура "хост/терминал"
  • 1.3. Архитектура "клиент/сервер"
  • 1.4. Заключение

Введение

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

Проанализируем основные варианты архитектур и платформ, использующихся для построения информационных систем.

1. Анализ архитектуры

1.1. Функции приложения

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

В соответствии с этим в любом приложении можно выделить следующие логические компоненты:

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

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

1.2. Архитектура "хост/терминал"

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

Рис. 1. Архитектура "хост/терминал".

Преимуществами данной архитектуры являются:

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

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

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

1.3. Архитектура "клиент/сервер"

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

1. Модель доступа к удаленным данным (Remote Data Access - RDA);
2. Модель сервера базы данных (DataBase Server - DBS);
3. Модель сервера приложений (Application Server - AS).

1.3.1. RDA-модель

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

Рис. 2. RDA-модель.

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

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

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

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

1.3.2. DBS-модель

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

Рис. 3. DBS-модель.

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

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

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

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

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

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

1.3.3. AS-модель

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

Рис. 4. AS-модель

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

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

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

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

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

Результаты анализа различных архитектур сведены в таблицу 1.1.3

Таблица 1.1.3.

1.4. Заключение

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

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

Дополнительная информация

• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов
• Подробнее о СУБД
• Статьи о СУБД
• Статьи об операционных системах
• Курсы: "Системное администрирование Windows NT 4.0" и "Microsoft SQL Server"

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме

INTERFACE Ltd. Телефон/Факс: +7 (495) 925-0049 Отправить E-Mail http://www.interface.ru

Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 16.05.03