Разработка АСР

      В настоящее время фактическим  стандартом для многопользовательских  СУБД, стала архитектура "клиент-сервер".

      Если  предполагается, что проектируемая  информационная система (ИС) будет построена  по технологии "клиент-сервер", то это означает, что прикладные программы, реализованные в ее рамках, будут  иметь распределенный характер. Иными  словами, часть функций прикладной программы (или, проще, приложения) будет  реализована в программе-клиенте, другая - в программе-сервере, причем для их взаимодействия будет определен  некоторый протокол.

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

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

• компонент представления, реализующий функции  первой группы;
• прикладной компонент, поддерживающий функции второй группы;
• компонент доступа к информационным ресурсам, поддерживающий функции третьей группы;
• протокол взаимодействия.

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

      Выделяются  четыре подхода, реализованные в  следующих моделях:  

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

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

      Рис.1. Модель файлового сервера. 

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

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

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

Рис 2. Модель доступа к удаленным данным. 

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

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

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

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

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

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

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

Рис.3. Модель сервера баз данных.

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

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

Рис. 4. Модель сервера приложений. 

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

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

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

      Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре систем с выделенным сервером, способным обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой (multi-threaded).