2.2. Варианты построения информационных приложений

Групповые и корпоративные информационные системы и соответствующие приложения могут строиться различными способами:

ü системы на основе локальной сети ПК (файл-серверные приложения);

ü системы с архитектурой клиент-сервер;

ü системы на основе Internet/Intranet-технологий.

Для лучшего понимания ограничений различных архитектур информационных систем, разделим приложения на типовые компоненты:

PS (Presentation Services) - средства представления. Обеспечиваются устройствами, принимающими ввод от пользователя и отображающим то, что сообщает ему компонент логики представления PL, плюс соответствующая программная поддержка. Может быть текстовым терминалом или Х-терминалом, а также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-терминала.

PL (Presentation Logic) - логика представления. Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе элемента из списка.

BL (Business or Application Logic) - прикладная логика. Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.

DL (Data Logic) - логика управления данными. Операции с базой данных (SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для реализации прикладной логики управления данными.

DS (Data Services) - операции с базой данных. Действия СУБД, вызываемые для выполнения логики управления данными, такие как манипулирование данными, определения данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.

FS (File Services) - файловые операции. Дисковые операции чтения и записи данных для СУБД и других компонент. Обычно являются функциями ОС. Можно привести несколько схем построения информационных систем в зависимости от размещения типовых компонентов приложения по узлам сети.

2.2.1. Файл-серверные приложения

Системы "файл-сервер" (Рисунок 1) не имеет сетевого разделения компонентов диалога PS и PL, использует ПК для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную мощность к сети.

Рисунок 1. «Варианты построения файл-серверных приложений»

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля или в виде специального кода для интерпретации.

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

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

Основой разработки файл-серверных приложений для локальных сетей ПК является инструментальное окружение различных "персональных" СУБД: FoxPro, Clipper, Paradox, Clarion, Paradox, dBase и т. п.

2.2.2. Приложения клиент-сервер

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

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

Большинство конфигураций клиент-сервер использует двухзвенную модель, состоящую из клиента, который обращается к услугам сервера (рисунок 2). Для эффективной реализации такой схемы часто применяют неоднородную сеть. Как минимум, предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Далее возможно разместить компоненты управления данными DS и FS на сервере, а диалог (PS, PL), логику BL и DL на клиенте. Типовое определение архитектуры клиент-сервер - приложение на клиенте, СУБД - на сервере - использует эту схему.

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