Во-вторых, удовлетворительное администрирование приложений в RDA-модели практически невозможно. Очевидно, что если различные по своей природе функции (функции представления и чисто прикладные функции) смешаны в одной и той же программе, написанной на языке 4GL, то при необходимости изменения прикладных функций приходится переписывать всю программу целиком. При коллективной работе над проектом, как правило, каждому разработчику поручается реализация отдельных прикладных функций, что делает невозможным контроль за их взаимной непротиворечивостью. Каждому из разработчиков приходится программировать интерфейс с пользователем, что ставит под вопрос единый стиль интерфейса и его целостность.
Во-первых, взаимодействие клиента и сервера посредством SQL-запросов существенно загружает сеть. Поскольку приложение является нераспределенным и вся его логика локализована на компьютере-клиенте, постольку приложение нуждается в передаче по сети данных большого объема, возможно, избыточных. Как только число клиентов возрастает, сеть превращается в "горлышко бутылки", тормозя быстродействие всей информационной системы.
RDA-модель имеет ряд ограничений.
Главное преимущество RDA-модели лежит в практической плоскости. Сегодня существует множество инструментальных средств, обеспечивающих быстрое создание desktop-приложений, работающих с SQL-ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Иными словами, основное достоинство RDA-модели заключается в унификации и широком выборе средств разработки приложений. Подавляющее большинство этих средств разработки на языках четвертого поколения ( включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления.
Модель сервера приложений.В чем заключается фундаментальное различие между этими моделями? RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором - интегрируется в компонент доступа к информационным ресурсам. Напротив, в AS-модели реализована классическая трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. Собственно, из этой особенности AS-модели и вытекают ее преимущества, которые имеют важнейшее значение для чисто практической деятельности.
В AS-модели (рисунок 3) процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за ввод и отображение данных (то есть реализует функции первой группы). Прикладные функции выполняются группой процессов (серверов приложений), функционирующих на удаленном компьютере (или нескольких компьютерах). Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается ровно тем же способом, что и в RDA-модели. Из прикладных компонентов доступны ресурсы различных типов - базы данных, индексированные файлы, очереди и др. Серверы приложений выполняются, как правило, на том же компьютере, где функционирует менеджер ресурсов, однако могут выполняться и на других компьютерах.Рисунок 3.
Модель сервера базы данных.На практике часто используются смешанные модели, когда поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель). Однако такие решения, включающие элементы сразу двух моделей, не могут принципиально изменить наших представлений о их соотношении.
Модель доступа к удаленным данным.DSB-модель (рисунок 2) строится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции реализованы в хранимых процедурах (stored procedure), которые также называют компилируемыми резидентными процедурами, или процедурами базы данных Они хранятся непосредственно в базе данных и выполняются на компьютере-сервере базы данных (где функционирует и компонент, управляющий доступом к данным, то есть ядро СУБД). Понятие информационного ресурса сужено до баз данных, поскольку механизм хранимых процедур - отличительная характеристика DBS-модели - имеется пока только в СУБД, да и то не во всех.Рисунок 2.
группы. Различия в реализации приложений в рамках технологии "клиент-сервер" определяются тремя факторами. Во-первых, тем, какие механизмы используются для реализации функций всех трех групп. В-третьих - как логические компоненты распределяются между компьютерами в сети. Выделяются три подхода, каждый из которых реализован в соответствующей модели:модель доступа к удаленным данным (Remote Date Access - RDA); модель сервера базы данных (DateBase Server - DBS); модель сервера приложений (Application Server - AS). В RDA-модели коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте, Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (языка SQL, например, если речь идет о базах данных) или вызовами функций специальной библиотеки ( если имеется соответствующий API). Запросы к информационным ресурсам направляются по сети удаленному компьютеру (например, серверу базы данных). Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных (рисунок 1). Говоря об архитектуре "клиент-сервер", в большинстве случаев имеют в виду именно эту модель.Рисунок 1.
или менеджер ресурсов (Resource manager), поддерживающий функции третьей
функции второй группы; компонент доступа к информационным ресурсам (resource acces)
первой группы; прикладной компонент (business application), поддерживающий
В соответствии с этим в любом приложении выделяются следующие логические компоненты:компонент представления (presentation), реализующий функции
Один из основных принципов технологии "клиент-сервер" заключается в разделении функций стандартного приложения на три группы, имеющие различную природу. Первая группа - это функция ввода и отображения данных. Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области. Наконец, к третьей группе относятся фундаментальные функции хранения и управления данными (базами данных, файловыми системами и т.д.)
Сегодня технология "клиент-сервер" получает все большее распространение, однако сама по себе она не предлагает универсальных рецептов. Она лишь дает общее представление о том, как должна быть организована современная распределенная информационная система. В то же время реализации этой технологии в конкретных программных продуктах и даже в видах программного обеспечения различаются весьма существенно.
Этот же принцип распространяется и на взаимодействие процессов. Если один из них выполняет некоторые функции, предоставляя другим соответствующий набор услуг, такой процесс рассматривается в качестве сервера. Процессы, пользующиеся этими услугами, принято называть клиентами.
"Клиент-сервер" - это модель взаимодействия компьютеров в сети. Редко бывает так, чтобы они были совершенно равноправными. Как правило, один компьютер в сети располагает информационно-вычислительными ресурсами, такими как процессоры, файловая система, почтовая служба, служба печати, база данных. Другие же компьютеры пользуются ими. Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса, а компьютер, желающий им воспользоваться - клиентом. Конкретный сервер характеризуется видом ресурса, которым он владеет. Так, если ресурсом являются базы данных, то речь идет о сервере баз данных, назначение которого - обслуживать запросы клиентов, связанные с обработкой баз данных; если ресурс - это файловая система, то говорят о файловом сервере или файл-сервере и т.д.
Часто программисты, приступающие к проектированию и реализации информационных систем, наталкиваются на ряд проблем и сложностей, происходящих не из их неопытности или недостаточных знаний, но имеющих своей причиной особенности и ограничения, внутренне присущие программным продуктам, имеющих архитектуру "клиент-сервер". Пытаясь решить эти проблемы, они зачастую вынуждены "изобретать велосипед" вместо того, чтобы использовать высокотехнологичные и стандартизованные средства создания распределенных промышленных информационных систем. К таким средствам и относятся мониторы транзакций.
Технология "клиент-сервер" и мониторы транзакций
Г. Ладыженский - Технология "клиент-сервер" и мониторы транзакций
Комментариев нет:
Отправить комментарий