В – третьих, при коллективной работе над проектом, обычно каждому разработчику поручается реализация отдельных прикладных функций, что делает невозможным контроль за их взаимной непротиворечивостью. Каждому из разработчиков приходится программировать интерфейс с пользователем, что ставит под вопрос единый стиль интерфейса и его целостность. Сложность обновления программного обеспечения возникает еще и потому, что замену ПО необходимо производить одновременно на всех компьютерах-клиентах.
В – четвертых, из-за невозможности реализации разграничения доступа по функциям только на стороне сервера, а только на стороне клиента, возникает низкий уровень безопасности. При этом разграничение выполняется только по таблицам базы данных, что снижает защищенность.
Несмотря на широкое распространение, RDA-модель уступает место более технологичной DBS-модели.
Модель сервера баз данных (DBS) - сетевая архитектура технологии «Клиент – сервер», основу которой составляет механизм хранимых процедур, реализующий прикладные функции. В DBS – модели понятие информационного ресурса сужено до базы данных из-за того же механизма хранимых процедур, который реализован в СУБД, да и то не во всех.
В DBS-модели приложение является распределенным. Компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент (реализующий бизнес-функции) оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Хранимые процедуры также называют компилируемыми резидентными процедурами или процедурами базы данных (рисунок 2).
Рисунок 2 - Модель сервера базы данных.
Преимущества DBS-модели перед RDA-моделью очевидны: это и возможность централизованного администрирования различных функций, и снижение трафика сети из-за того, что вместо SQL-запросов по сети передаются вызовы хранимых процедур, и возможность разделения процедуры между несколькими приложениями, и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры. Однако есть и недостатки.
Во-первых, разнообразные процедурные расширения SQL, используемые для написания хранимых процедур, не являются языками программирования в полном смысле слова. Они встроены в конкретные СУБД и имеют ограниченные возможности. Следовательно, система, в которой прикладной компонент реализован при помощи хранимых процедур, не является мобильной относительно СУБД. В большинстве СУБД отсутствуют возможности отладки и тестирования хранимых процедур, что может привести не просто к сбою, а к полной неработоспособности всей базы данных.
Во-вторых, в DBS-модели не предусмотрены разнообразные варианты взаимодействия клиента и сервера, необходимые для децентрализация приложений, например хранимые очереди, асинхронные вызовы и другие.
В-третьих, DBS-модель не обеспечивает требуемой эффективности использования вычислительных ресурсов. Ограничения в ядре СУБД не позволяют в полной мере организовать эффективный баланс загрузки, миграцию процедур на другие компьютеры-серверы БД и реализовать другие полезные функции, например запросы с приоритетом.
На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем: поддержка целостности базы данных и некоторых простейших прикладные функции хранимых процедур (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).
Все недостатки DBS - модели учтены в AS-модели, которая в наибольшей степени отражает сильные стороны технологии «клиент-сервер».
Модель сервера приложений (AS) (рисунок 3)- сетевая архитектура технологии «Клиент – сервер», представляющая собой процесс, выполняемый на компьютере-клиенте и отвечающий за интерфейс с пользователем (ввод и отображение данных). Основным элементом данной модели является прикладной компонент, называющийся сервером приложения, функционирующий на удаленном компьютере (или нескольких компьютерах). Сервер приложений реализован как группа прикладных функций, оформленных в виде сервисов (служб). Каждый сервис предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться.
Рисунок 3 - Модель сервера приложений.
Серверов приложений может быть несколько, и каждый их них предоставляет определенный набор услуг. Любая программа, которая пользуется ими, рассматривается как клиент приложения.
Детали реализации прикладных функций в сервере приложений полностью скрыты от клиента приложения. Клиент, которым может быть стандартный браузер, обращается с запросом к конкретной службе, при этом серверы приложений обезличены и служат для создания графического интерфейса с пользователем, что позволяет эффективно управлять балансом загрузки. Запросы, поступающие от клиента, выстраиваются в очередь к AS-процессу, который извлекает и передает их для обработки службе в соответствии с приоритетами.
Так как данные «спрятаны» за сервером приложений, в котором обычно встроена проверка полномочий клиента, в СУБД обеспечивается высокий уровень защиты данных.
Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается как и в RDA-модели менеджером ресурсов (например, SQL-сервер). Из прикладных компонентов доступны такие ресурсы как, базы данных, очереди, почтовые службы и другие. Серверы приложений выполняются, как правило, на том же компьютере, где функционирует менеджер ресурсов, что избавляет от необходимости направления SQL-запросов по сети и повышает производительность системы, Также серверы приложений могут выполняться и на других компьютерах.
AS-модель является универсальной системой, в которой может быть сколько угодно уровней, взаимодействующих между собой. Четкое разграничение логических компонентов, возможность баланса загрузки между несколькими серверами, и рациональный выбор программных средств для их реализации обеспечивают модели такой уровень гибкости, защиты данных и открытости, который пока недостижим в RDA- и DBS-моделях. В AS-модели возможна работа по медленным линиям связи, что значительно снижает трафик между клиентом и сервером приложений. Исходя из выше сказанного, именно AS-модель является фундаментом для мониторов обработки транзакций.
Изучив все модели технологии «Клиент – сервер», можно сделать следующий вывод: RDA- и DBS-модели имеют в основе двухзвенную схему разделения функций. В RDA-модели прикладные функции отданы клиенту, в DBS-модели их реализация осуществляется через ядро СУБД. В RDA-модели прикладной компонент сливается с компонентом представления, в DBS-модели интегрируется в компонент доступа к ресурсам.
В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, имеющий стандартизированные интерфейсы с двумя другими компонентами.
Результаты анализа моделей технологий «Файловый сервер» и «Клиент – сервер» представлены в таблице 1.
Несмотря на свое названия технология «Клиент –сервер» также является системой распределенных вычислений. В данном случае распределенные вычисления рассматриваются как архитектура «Клиент – сервер» с участием нескольких серверов. Применительно к распределенной обработке термин «сервер» означает просто программу, отвечающую на запросы и выполняющую необходимые действия по запросу клиента. Поскольку распределенные вычисления - это один из видов систем «Клиент – сервер», то пользователи получают такие же преимущества, например, увеличение общей пропускной способности и возможность многозадачной работы. Кроме того, интеграция дискретных сетевых компонентов и обеспечение их функционирования как единого целого способствует увеличению эффективности и снижению издержек.
Так как обработка осуществляется в любом месте сети, распределенные вычисления в архитектуре «Клиент–сервер» гарантируют эффективное масштабирование. Чтобы добиться баланса между клиентом и сервером, компонент приложения должен выполняться на сервере только в том случае, когда централизованная обработка более эффективна. Если логика программы, взаимодействующей с централизованными данными, сосредоточена на той же машине, что и данные, их необязательно передавать по сети, поэтому требования к сетевой среде могут быть снижены.
Таким образом, если предстоит работа с небольшими информационными системами, не требующими графического интерфейса с пользователем, можно выбрать FS - модель. Проблему графического интерфейса легко решает RDA-модель. DBS-модель является хорошим вариантом для СУБД. AS-модель является лучшим вариантом для создания больших информационных систем, а также в случае использования низкоскоростных каналов связи.
Таблица 1 - Результаты анализа моделей технологий «Файловый сервер» и «Клиент – сервер»
Критерии | «Файловый сервер» | «Клиент – сервер» | ||
FS - модель | RDA-модель | DBS-модель | AS-модель | |
1 | 2 | 3 | 4 | 5 |
Сложность разработки приложений | Низкая | Низкая | Высокая | Высокая |
Сложность администрирования | Низкая | Высокая | Высокая | Высокая |
Степень защиты данных | Высокая | Низкая | Высокая | Высокая |
Требования к характеристикам сервера | Высокие | Низкие | Высокие | Высокие |
Трафик, создаваемый в сети | Низкий | Очень высокий | Низкий | Низкий |
Сложность обновления ПО | Низкая | Высокая | Низкая | Низкая |
Требования к характеристикам сети | Низкие | Очень высокие | Низкие | Низкие |
Распределение загрузки | Нет | Есть | Есть | Есть |
Требования к характеристикам рабочих станций | - | Очень высокие | Низкие | Низкие |
Использование графического интерфейса | - | + | + | + |
Использование символьного интерфейса | + | + | + | + |
При разработке любой информационной системы можно использовать модели как в чистом виде, так и их объединение. Для этого необходимо правильно определиться не только с моделью, но и с платформой, на которой она будет реализована, так как ошибки, допущенные на этом этапе, могут свести на нет все преимущества прикладной части информационной системы. Причем большая часть недостатков, вызванных этими ошибками, выясняется, как правило, только на этапе эксплуатации.