Логические компоненты приложений «клиент-сервер»
Один из основных принципов технологии "клиент-сервер" заключается в разделении функций стандартного приложения на три группы, имеющие различную природу. Первая группа - это функция ввода и отображения данных. Ко второй группе относятся фундаментальные функции хранения и управления данными (базами данных, файловыми системами и т.д.). Третья группа объединяет чисто прикладные функции, характерные для данной предметной области. Наконец,
В соответствии с этим в любом приложении выделяются следующие логические компоненты:
• компонент представления, реализующий функции первой группы;
• компонент доступа к информационным ресурсам или менеджер ресурсов, поддерживающий функции второй группы;
• прикладной компонент, поддерживающий функции третьей группы.
В связи с этим разделением выделяются три модели реализации приложений в рамках технологии «клиент-сервер»:
• модель доступа к удаленным данным (Remote Date Access - RDA);
• модель сервера базы данных (DateBase Server - DBS);
• модель сервера приложений (Application Server - AS).
Rda-модель
В RDA-модели коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте. Клиент поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается операторами специального языка, например, языка SQL. Запросы к информационным ресурсам направляются по сети серверу базы данных. Сервер БД обрабатывает и выполняет запросы и возвращает клиенту блоки данных (рисунок 1). Приложение является нераспределенным.
Модель доступа к удаленным данным.
Основное достоинство RDA-модели заключается в унификации и широком выборе средств разработки приложений. Т.е. главное преимущество RDA-модели в том, что сегодня существует множество инструментальных средств, обеспечивающих быстрое создание приложений, работающих с SQL-ориентированными СУБД. Большинство из этих средств поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC, содержат средства автоматической генерации кода.
RDA-модель имеет ряд ограничений:
Во-первых, взаимодействие клиента и сервера посредством SQL-запросов существенно загружает сеть. Поскольку приложение является нераспределенным и вся его логика локализована на компьютере-клиенте, постольку приложение нуждается в передаче по сети данных большого объема, возможно, избыточных. Как только число клиентов возрастает, сеть превращается в "горлышко бутылки", тормозя быстродействие всей информационной системы.
Во-вторых, удовлетворительное администрирование приложений в RDA-модели практически невозможно. При коллективной работе над проектом, как правило, каждому разработчику поручается реализация отдельных прикладных функций, что делает невозможным контроль за их взаимной непротиворечивостью. Каждому из разработчиков приходится программировать интерфейс с пользователем, что ставит под вопрос единый стиль интерфейса и его целостность.
Dbs-модель
DSB-модель строится исходя из следующих соображений. Процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления. Прикладные функции реализованы в хранимых процедурах базы данных. Они хранятся непосредственно в базе данных и выполняются на сервере базы данных. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL. Он уникален для каждой конкретной СУБД. Попытки стандартизации языка SQL, касающиеся хранимых процедур, пока не привели к ощутимому успеху. В DBS-модели приложение является распределенным.
Модель сервера базы данных.
Преимущества DBS-модели перед RDA-моделью:
возможность централизованного администрирования бизнес-функций,
снижение трафика сети,
возможность разделения процедуры между несколькими приложениями,
экономия ресурсов за счет использования единого плана выполнения процедуры.
Однако есть и недостатки:
Во-первых, средства, используемые для написания хранимых процедур, уступают по изобразительным средствам и функциональным возможностям таким языкам, как C или Pascal. Они встроены в конкретные СУБД, и рамки их использования ограничены. Следовательно, система, в которой прикладной компонент реализован при помощи хранимых процедур, является непереносимой относительно СУБД.
Во-вторых, DBS-модель не обеспечивает требуемой эффективности использования вычислительных ресурсов. Объективные ограничения в ядре СУБД не позволяют пока организовать в его рамках эффективный баланс загрузки, миграцию процедур на другие компьютеры-серверы БД и реализовать другие полезные функции. Попытки разработчиков СУБД предусмотреть в своих системах эти возможности (распределенные хранимые процедуры, запросы с приоритетами и т. д.) пока не позволяют добиться желаемого эффекта.
В-третьих, в DBS-модели не поддерживаются такие механизмы взаимодействия, как хранимые очереди, асинхронные вызовы, которые необходимы для нормальной работы децентрализованных приложений.
Сегодня вряд ли можно говорить о том, что хранимые процедуры в их нынешнем состоянии представляют собой адекватный механизм для описания бизнес-функций и реализации прикладного компонента. Для того, чтобы превратить их в действительно мощное средство, разработчики СУБД должны воспроизвести в них следующие возможности: