Глава 7

ТЕХНОЛОГИИ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ИНФОРМАЦИИ

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

7.1. Распределенные базы данных

Следует отметить, что общая тенденция развития технологий обработки данных вполне соответствует этапам развития средств вычислительной техники и информационных технологий, и в первую очередь — сетевых.

Распределенные системы

Следует выделить два класса систем распределенной обработки и системы распределенных данных:

• системы распределенной обработки в основном отражают структуру и свойства многопользовательских операцион­ных систем с базой данных, размешенной на центральном компьютере;

• системы распределенных данных обеспечивают обработку распределенных запросов, когда при обработке одного за­проса используются информационные ресурсы, размещен­ные на различных ЭВМ сети. При этом, как и ранее, сле­дует говорить как о распределенных файловых системах, так и о распределенных базах данных.

Для распределенных баз данных свойственны следующие ха­рактеристики:

• база данных — это логически связанные, разделяемые на некоторое количество фрагментов данные;

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

• может быть предусмотрена репликация фрагментов;

• доступ к данным на каждом узле происходит под управле­нием СУБД, которая на каждом узле должна поддерживать работу как локальных приложений, так и глобальных.

Основные условия и требования к распределенной обработке данных:

• прозрачность относительно расположения данных (СУБД должна представлять все данные так, как если бы они были локальными);

• гетерогенность системы (СУБД должна работать с данны­ми, которые хранятся в системах с различной архитектурой и производительностью);

• прозрачность относительно сети (СУБД должна одинаково работать в условиях разнородных сетей);

• поддержка распределенных запросов (пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах);

• поддержка распределенных изменений (пользователь дол­жен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах);

• поддержка распределенных транзакций (СУБД должна вы­полнять транзакции, выходящие за рамки одной вычисли­тельной системы, и поддерживать целостность распреде­ленной БД даже при возникновении отказов как в отдель­ных системах, так и в сети);

• безопасность (СУБД должна обеспечивать защиту всей рас­пределенной БД от несанкционированного доступа);

• универсальность доступа (СУБД должна обеспечивать еди­ную методику доступа ко всем данным).

Поясним некоторые из этих требований:

Прозрачность расположения. Прозрачный (для пользователя) доступ к удаленным данным предполагает использование в при­кладных программах такого интерфейса с сервером БД, который позволяет переносить данные в сети с одного узла на другой, не требуя при этом модификации текста программы. Иными слова­ми, доступ к информационным ресурсам должен быть полно­стью прозрачен относительно расположения данных.

Любой пользователь или любая прикладная программа опе­рирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на од­ном и том же узле, проблемы расположения не возникает. Для получения доступа к базе данных пользователю или программе достаточно указать имя базы, например: SQL Dbr.arr.e.

Однако в том случае, когда прикладная программа запуска­ется на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того чтобы получить доступ к базе данных на удаленном узле, необ­ходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре «имя_узла, имя_БД», то прикладная программа становится за­висимой от расположения БД. Например, обращение к БД «host: stock», где первый компонент — имя узла, будет зависи­мым от расположения.

Одно из возможных решений этой проблемы состоит в ис­пользовании виртуальных имен узлов. Управление ими обеспе­чивается специальным программным компонентом СУБД — сервером имен (Name Server), который адресует запросы клиен­тов к серверам.

Прозрачность сети. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечи­вать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обес­печить прозрачный доступ пользователей и программ к удален­ным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно бо­лее широкий диапазон сетевых протоколов (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, AppleTalk и др.).

Автоматическое преобразование форматов данных. Как толь­ко несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу воз­никает вопрос о согласовании форматов представления данных. Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (16-, 32- и 64-разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т. д. Задача коммуникационного сервера состоит в том, чтобы на уровне обмена данными обеспечить согласование фор­матов между удаленным и локальным узлами с тем, чтобы дан­ные, извлеченные сервером из базы на удаленном узле и пере­данные по сети, были правильно истолкованы прикладной про­граммой на локальном узле.

Автоматическая трансляция кодов. В неоднородной компью­терной среде при взаимодействии клиента и сервера возникает также задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент — с другой (на­пример, ASCII), при этом происходит рассогласование трактов­ки кодов символов. Поэтому, если на локальном узле использу­ется одна кодовая таблица, а на удаленном — другая, то при пе­редаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер.

Однако ни одна из существующих СУБД не дос­тигает этого идеала вследствие следующих практических проблем:

• низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях силь­но снижает общую производительность обработки;

• обеспечение целостности данных в распределенных тран­закциях базируется на принципе «все или ничего» и требу­ет специального протокола двухфазного завершения тран­закций, что приводит к длительной блокировке изменяе­мых данных;

• необходимо обеспечить совместимость данных стандартно­го типа, для хранения которых в разных системах исполь­зуются разные физические форматы и кодировки;

• трудности выбора схемы размещения системных каталогов. Если каталог будет храниться в одной системе, то удален­ный доступ будет замедлен. Если будет размножен, то из­менения придется распространять и синхронизировать;

« необходимо обеспечить совместимость СУБД разных типов и поставщиков;

• увеличение потребностей в ресурсах для координации ра­боты приложений с целью обнаружения и устранения ту­пиковых ситуаций в распределенных транзакциях.

Типы распределенных СУБД

В общем случае режимы работы с БД можно классифициро­вать по следующим признакам:

• многозадачность — однопользовательский или многополь­зовательский;

• правило обслуживания запросов — последовательное или параллельное;

• схема размещение данных — централизованная или рас­пределенная БД.

Распределенные СУБД подразделяются на однородные и раз­нородные.

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

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

Очевидны следующие преимущества и недостатки распреде­ленных баз данных (табл. 7.1).

Таблица 7.1. Некоторые характеристики распределенных БД

Преимущества	Недостатки
Соответствие структуре организации	Повышение сложности
Локальная автономность	Увеличение стоимости согласования
Повышение доступности данных	Проблемы защиты
Повышение надежности	Контроль целостности данных
Повышение производительности	Затрудненность унификации
Экономические выгоды	Высокая информационная квалификация
Модульность системы	Усложнение процедуры разработки БД

Распределенная СУБД должна иметь следующий набор функциональных возможностей:

. расширенные службы установки соединений должны обес­печивать доступ к удаленным узлам и позволять передавать запросы и данные между узлами, входящими в сеть;

• расширенные средства ведения каталога, позволяющие со­хранять сведения о распределении данных в сети;

• средства обработки распределенных запросов, включая ме­ханизмы оптимизации запросов и организации удаленного доступа к данным;

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

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

• расширенные функции восстановления, учитывающие ве­роятность отказов в работе отдельных узлов и отказов ли­ний связи.

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

7.2. Клиент-серверные архитектуры распределенной обработки данных

Практически все модели организации взаимодействия поль­зователя с базой данных, построены на основе модели «кли­ент — сервер». То есть предполагается, что приложения, реали­зующие какой-либо тип модели, отличаются способом распреде­ления функций ранее приведенных групп обработки данных между как минимум двумя частями:

• клиентской, которая отвечает за целевую обработку данных и организацию взаимодействия с пользователем;

• серверной, которая обеспечивает хранение данных, обраба­тывает запросы и посылает результаты клиенту для специ­альной обработки.

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

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

Клиент — это различные программы, написанные как пользователями, так и поставщиками СУБД, внешние или «встроенные» по отношению к СУБД. Программа-клиент орга­низована в виде приложения, работающего «поверх» СУБД и об­ращающегося для выполнения операций над данными к компо­нентам СУБД через интерфейс внешнего уровня. Инструмен­тальные средства, в том числе и утилиты, не отнесены к серверной части очень условно. Являясь не менее важной со­ставляющей, чем ядро СУБД, они выполняются самостоятельно, как пользовательское приложение.

Основной принцип технологии «клиент—сервер» заключает­ся в разделении функций стандартного интерак­тивного приложения на четыре группы, имеющие различ­ную природу:

• функции ввода и отображения данных;

• чисто прикладные функции, характерные для данной предметной области (например, для банковской систе­мы — открытие счета, перевод денег с одного счета на другой и т. д.);

• фундаментальные функции хранения и управления инфор­мационными ресурсами (базами данных, файловыми сис­темами и т. д.);

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

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

• файловый сервер (File Server — FS);

• доступ к удаленным данным (Remote Data Access — RDA);

• север базы данных (DataBase Server — DBS);

• сервер приложений (Application Server — AS).

Файловый сервер (FS)

Модель является базовой для локальных сетей персональных компьютеров. В свое время она была исключительно популяр­ной среди отечественных разработчиков, использовавших такие системы, как FoxPRO, Clipper, Clarion, Paradox и т. д. Один из компьютеров в сети считается файловым сервером и предостав­ляет услуги по обработке файлов другим компьютерам. Здесь мы имеем дело с распределенной файловой системой. Файловый сер­вер работает под управлением сетевой операционной системы (например, Novell NetWare) и играет роль компонента доступа к информационным ресурсам (т. е. к файлам). На других компью­терах в сети функционируют приложения, в кодах которых со­вмещены компонент представления и прикладной компонент (рис. 7.1, а). Протокол обмена представляет собой набор низко­уровневых вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.

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

Клиент				Запросы		Сервер
		Прикладной
	Компонент					Компонент доступа
	представления			Файлы

а

в

Клиент			Сервер			SQL	Сервер
Компонент		API		Прикладной компонент				Компонент доступа
представления		< >						к ресурсам

Рис. 7.1. Разновидности архитектур «клиент—сервер»; а — модель файлового сервера; о — модель доступа к удаленным данным; в — модель сервера базы данных; г — модель сервера приложений

сервер направляет по сети требуемый блок данных. СУБД, полу­чив его, выполняет над данными действия, которые были декла­рированы в прикладной программе.

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

Уделенный доступ (RDA)

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

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

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

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

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

Сервер баз данных (DBS)

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

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

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

Сервер приложении (AS)

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

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

ТРМ), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения.

В заключение отметим, что часто, говоря о сервере базы дан­ных, подразумевают как компьютер, так и программное обеспе­чение — ядро СУБД. При описании архитектуры «клиент — сер­вер» под сервером базы данных мы имели в виду компьютер. Ниже сервер базы данных будет пониматься как программное обеспечение — ядро СУБД.

7.3. Архитектура сервера баз данных

Эволюция серверов баз данных

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

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

Проблемы, возникающие в модели «один к одному», реша­ются в архитектуре систем с выделенным сервером, спо­собным обрабатывать запросы от многих клиентов. Сервер обла­дает монополией на управление данными и взаимодействует од-

ш □ □

Ш □ □ Ф

41/ 1

ш □ □ □

\/ \/

ш □

Рис. 7.2. Разновидности серверов БД: а — централизованная архитектура; б — архитектура «один к одному»; в — разме­щение клиента и сервера на различных машинах; г — многопотоковая архитектура; д — архитектура с виртуальным сервером; е — многопотоковая мультисерверная ар­хитектура; 1 — клиент; 2 — сервер; 3 — диспетчер; 4 — многопотоковый сервер

Сеть

□ъ □

EEf □ □□

б

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

системы. Например, системой с архитектурой «один к одному» будет создано 50 копий процессов СУБД для 50 пользователей, тогда как системе с многопотоковой архитектурой для этого по­надобится только один сервер.

Однако такое решение привносит новую проблему. Так как сервер может выполняться только на одном процессоре, возни­кает естественное ограничение на применение СУБД для муль­типроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с одним сервером используют только один из них, не загружая оставшиеся три.

В некоторых системах эта проблема решается заменой выде­ленного сервера на д и с п е тч е р или виртуальный сервер (virtual server) (рис. 7.2. д), который теряет право монопольно распоряжаться данными, выполняя только функции диспетчери­зации запросов к актуальным серверам. Таким образом, в архи­тектуру системы добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки (load balancing) и ограничивает воз­можности управления взаимодействием «клиент — сервер». Во-первых, становится невозможным направить запрос от кон­кретного клиента конкретному серверу, во-вторых, серверы ста­новятся равноправными — невозможно устанавливать приорите­ты для обслуживания запросов.

Современное решение проблемы СУБД для мультипроцес­сорных платформ заключается в возможности запуска несколь­ких серверов базы данных, в том числе и на различных процес­сорах. При этом каждый из серверов должен быть многопотоко­вым. Если два эти условия выполнены, то есть основание говорить о многопотоковой архитектуре с несколь­кими серверами (multi-threaded, multi-server architecture), представленной на рис. 7.2, е.

Повышение эффективности и оперативности обслуживания большого числа клиентских запросов, помимо простого увеличе­ния ресурсов и вычислительной мощности серверной машины, может быть достигнуто двумя путями:

• снижением суммарного расхода памяти и вычислительных ресурсов за счет буферизации (кэширования) и совместно­го использования (разделяемые ресурсы) наиболее часто запрашиваемых данных и процедур;

• распараллеливанием процесса обработки запроса — ис­пользованием разных процессоров для параллельной обра­ботки изолированных подзапросов и/или для одновремен­ного обращения к частям базы данных, размещенным на отдельных физических носителях.

Таким образом, типология распределенных баз данных опре­деляется схемой распределения данных между узлами и схемой распараллеливания процессов обработки запросов.

Рассмотрим архитектуры, реализующие следующие модели совместной обработки клиентских запросов.

Как уже отмечалось, для однопроцессорных архитектур воз­можны схемы следующих типов:

• однопотоковые архитектуры — «один к одному», когда для обслуживания каждого запроса запускается отдельный сер­верный процесс. В этом случае, даже если от клиентов по­ступят совершенно одинаковые запросы, для обработки ка­ждого из них будет запущен отдельный процесс, каждый из которых будет выполнять одинаковые действия и исполь­зовать одни и те же ресурсы;

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

В общем случае для повышения оперативности за счет рас­параллеливания процесса обработки отдельного клиентского за­проса в мультисерверной архитектуре можно использовать сле­дующие подходы:

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

• запрос обрабатывается по конвейерной технологии. Для этого запрос разбивается на взаимосвязанные по результа­там подзапросы, каждый из которых может быть обслужен отдельным серверным процессом независимо от обработки других подзапросов. Получаемые результаты объединяются согласно схеме декомпозиции запроса и передаются клиен­ту. Такой тип распараллеливания называют моделью верти­кального параллелизма. Схема обработки клиентского запроса, построенная с ис­пользованием обеих моделей параллелизма (гибридная модель), приведена на рис. 7.3.

Рис. 7.3. Архитектура сервера обработки запроса при гибридном параллелизме

Отдельно необходимо упомянуть «интеграционный» под­ход — использование мулыпибазовой СУБД, которая размешается над существующими системами баз данных и файловыми систе­мами и позволяет пользователям рассматривать совокупность баз данных (и, возможно, под управлением разнотипных СУБД) как единую базу. Мультибазовая СУБД поддерживает глобаль­ную схему, на основании которой пользователи могут формиро­вать запросы и модифицировать данные. Мультибазовая СУБД работает только с глобальной схемой, тогда как локальные СУБД могут использовать собственные схемы представления и обработки «своих» данных.

Активный сервер

В распределенных БД возникают следующие проблемы: • база данных в любой момент времени должна правильно отражать состояние предметной области — дан­ные должны быть взаимно непротиворечивыми. Пусть, например, база данных Кадры хранит сведения о рядовых

сотрудниках, отделах, в которых они работают, и их руко­водителях. Нужно учесть следующие правила: каждый со­трудник должен быть подчинен реальному руководителю; если руководитель уволился, то все его сотрудники пере­ходят в подчинение другому, а отдел реорганизуется; во главе каждого отдела должен стоять реальный руководи­тель; если отдел сокращен, то его руководитель перево­дится в резерв на выдвижение и т. д.;

• база данных должна отражать некоторые правила предметной области, законы, по которым она функ­ционирует (business rules). Завод может нормально работать только в том случае, если на складе имеется достаточный запас деталей определенной номенклатуры. Следовательно, как только количество деталей некоторого типа станет меньше минимально допустимого, завод должен докупить их в нужном количестве;

• необходим постоянный контроль за состоянием базы данных, отслеживание всех изменений и адекват­ная реакция на них. Например, в автоматизированной сис­теме управления производством датчики контролируют температуру инструмента; она периодически передается в базу данных и там сохраняется; как только температура ин­струмента превышает максимально допустимое значение, он отключается;

• необходимо, чтобы возникновение некоторой ситуа­ции в базе данных четко и оперативно влияло на ход выполнения прикладной программы. Многие про­граммы требуют оперативного оповещения обо всех про­исходящих в базе данных изменениях. Так, в системах ав­томатизированного управления производством необходимо моментально уведомлять программы о любых изменениях параметров технологических процессов, когда последние хранятся в базе данных. Почтовая служба требует опера­тивного уведомления получателя, как только получено но­вое сообщение;

• важная функция — контроль типов данных. В базе данных каждый столбец в любой таблице содержит данные некоторых типов. Тип данных определяется при создании таблицы. Каждому столбцу присваивается один из стан­дартных типов данных, разрешенных в СУБД.

Концепция активного сервера опирается на следую­щие принципы:

• процедуры базы данных;

• правила (триггеры);

• события в базе данных.

Процедуры базы данных. В различных СУБД они носят назва­ние хранимых (stored), присоединенных, разделяемых и т. д. Ниже используется терминология, принятая в СУБД Ingres.

Использование процедур базы данных преследует четыре цели:

• обеспечивается новый независимый уровень центра­лизованного контроля доступа к данным, осущест­вляемый администратором базы данных;

• одна и та же процедура может использоваться несколькими прикладными программами — это позволяет существенно сократить время написания программ за счет оформления их общих частей в виде про­цедур базы данных. Процедура компилируется и помеща­ется в базу данных, становясь доступной для многократ­ных вызовов. Так как план ее выполнения определяется единожды при компиляции, то при последующих вызовах процедуры фаза оптимизации пропускается, что сущест­венно экономит вычислительные ресурсы системы;

• значительное снижение трафика сети в системах с архитектурой «клиент — сервер». Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся фрагменты из нескольких прикладных программ (рис. 7.4). Если бы эти фрагменты остались ча­стью программы, они загружали бы сеть посылкой полных SQL-запросов;

• процедуры базы данных в сочетании с правилами, о ко­торых речь пойдет ниже, предоставляют администратору мощные средства поддержки целостности базы данных.

Процедура обычно хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается опера­тором create procedure (создать процедуру) и содержит оп­ределения переменных, операторы SQL (например, select, insert), операторы проверки условий (if/then/else), опера­торы цикла (for, while), а также некоторые другие.

Рис. 7.4. Увеличение производительности за счет использования процедур баз

данных:

а — процедуры не используются: б — выделение фрагмента прикладных про­грамм в виде процедуры БД

Пусть, например, необходимо разработать процедуру, кото­рая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность. Процедура Назначение перемещает строки из таблицы Сотрудник, которая содержит сведения о со­трудниках, в таблицу Резерв для всех сотрудников с указанным номером. Номер сотрудника представляет собой целое число (тип integer), который не может иметь пустое значение, явля­ется параметром процедуры и передается ей при вызове из при­кладной программы оператором execute procedure (выпол­нить процедуру) :

CREATE PROCEDURE Назначение

(Номер сотрудника integer not nul)

AS

BEGIN

INSERT INTO Резерв

SELECT *

FROM Сотрудник

WHERE Номер = Номер_сотрудника;

DELETE

FROM Сотрудник

WHERE Номер = Номер сотрудника;

END.

Правша. Механизм правил (триггеров) позволяет програм­мировать обработку ситуаций, возникающих при любых измене­ниях в базе данных.

Правило придается таблице базы данных и применяется при выполнении над таблицей операций включения, удаления или обновления строк.

Одна из целей механизма правил — отражение некоторых внешних правил деятельности организации. Пусть, например, в базе данных Склад содержится таблица Деталь, хранящая сведе­ния о наличии деталей на складе завода. Одно из правил дея­тельности завода заключается в том, что недопустима ситуация, когда на складе число деталей любого типа становится меньше некоторого числа (например, 1000).

Это требование может быть описано правилом Прове- рить_деталь. Оно применяется в случае обновления столбца Количество таблицы Деталь: если новое значение в столбце меньше 1000, то выполняется процедура Заказать_деталь. В качестве параметров ей передаются номер детали данного типа и остаток (число детатей на складе):

CREATE RULE ПроЕерить_деталь

AFTER UPDATE (Количество) OF деталь

WHERE Деталь.Количество < 1000

EXECUTE PROCEDURE Заказать_деталь

(Номер детали = Деталь.Номер,

Остаток - Деталь.Количество).

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

Важнейшая цель механизма правил — обеспечение целост­ности базы данных. Один из аспектов целостности — целост­ность по ссылкам (referential integrity) — относится к связи двух таблиц между собой.

Допустим, таблица Руководитель содержит сведения о на­чальниках, а таблица Сотрудник — о сотрудниках некоторой ор­ганизации (см. рис. 5.6). Столбец Номер_руководителя являет­ся внешним ключом таблицы Сотрудник и ссылкой на таблицу

Руководитель.

Для обеспечения целостности ссылок должны быть учтены два требования. Во-первых, если в таблицу Сотрудник добавля­ется новая строка, значение столбца номер руководителя должно быть взято ИЗ множества значений столбца Номер таблицы Ру­ководитель (сотрудник может быть подчинен только реальному руководителю). Во-вторых, при удалении любой строки из таб­лицы Руководитель В таблице Сотрудник не ДОЛЖНО остаться ни одной строки, в которой в столбце Номер_руководителя было бы значение, тождественное значению столбца Номер в удаляемой строке (все сотрудники, если их руководитель уволил­ся, должны перейти в подчинение другому).

Для того чтобы учесть эти требования, должны быть созданы правила, их реализующие. Первое правило Добавить_сотруд- ника срабатывает при включении строки в таблицу Сотрудник; его применение заключается в вызове процедуры Прове- рить_руководителей, устанавливающей, существует ли среди множества значений столбца Номер таблицы Руководитель зна­чение, тождественное значению поля Номер_руководителя до­бавляемой строки. Если это не так, процедура должна ее отверг­нуть. Второе правило применяется при попытке удалить строку из таблицы Руководитель; оно состоит в вызове процедуры, ко­торая сравнивает значения в столбце Номер_рукозодителя таб­лицы Сотрудник со значением поля Номер в удаляемой строке. В случае совпадения значение в столбце Номер_руководителя обновляется.

CREATE RULE Добавить_сструдника

AFTER INSERT INTO Сотрудник

EXECUTE PROCEDURE

Проверить_руксводителя

(Номер = Сотрудник.Номер_руксводктеля).

Механизм правил позволяет реализовать и более общие огра­ничения целостности. Пусть, например, таблица Сотрудник со­держит информацию о сотрудниках, в том числе имя и название отдела, в котором они работают. Таблица Отдел хранит для каж­дого отдела количество работающих в нем сотрудников в столб­це Количество__сотруднихоз. Одно из ограничений целостно­сти заключается в том, что это количество должно совпадать с числом строк для данного отдела в таблице Сотрудник. Чтобы учесть это ограничение, можно использовать правило Доба­вить сотрудника, которое применяется при включении строки в таблицу Сотрудник и запускает процедуру нозый_сотрудник. Она, в свою очередь, обновляет значение столбца количест­во сотрудников, увеличивая его на единицу. Параметр проце­дуры — название отдела.

CREATE RULE

AFTER INSERT JNTO Сотрудник

EXECUTE PROCEDURE Нсвь:й_сотрудШк

(Отдел = Сотрудник.Отдел).

Разумеется, на практике с помощью механизма правил реализуются более сложные и изощренные ограничения цело­стности.

Аналогом правил послужили триггеры (triggers), которые впервые появились в СУБД Sybase и впоследствии были реали­зованы в том или ином виде и под тем или иным названием в большинстве многопользовательских СУБД.

События в базе данных. Механизм событий в базе данных (database events) позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, часто называют сигнализаторами событий в базе данных (database event alerters). Функции управления событиями цели­ком ложатся на сервер базы данных.

Рисунок 7.5 иллюстрирует один из примеров использования механизма событий: различные прикладные программы и проце­дуры вызывают события в базе данных, а сервер оповещает мо­нитор прикладных программ об их наступлении. Реакция мони­тора на события заключается в выполнении действий, которые предусмотрел его разработчик.

Механизм событий используется следующим образом. Вна­чале в базе данных для каждого события создается флажок, со­стояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор create dbevent - создать событие). Далее, во все прикладные про­граммы, на ход выполнения которых может повлиять это собы-

Сервер DBMS

Уведомление о событии

1

Программа

Рис. 7.5. События в базе данных

тие, включается оператор register dbevent (зарегистриро­вать событие), который оповещает сервер базы данных, что программа заинтересована в получении сообщения о наступле­нии события. Теперь любая прикладная программа или процеду­ра базы данных может вызвать событие оператором raise dbevent (вызвать событие) . Как только событие произошло, каждая зарегистрированная программа может получить его, для чего она должна запросить очередное сообщение из очереди со­бытий (оператор get dbevent — получить событие) и запро­сить информацию о событии, в частности его имя (оператор SQL inquire_sql).

Следующий пример иллюстрирует обработку всех событий из очереди:

loop

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL (:event_name =

DBEVENTNAME);

if (event_name = 'event_l')

обработать событие event_i

else if (event_name = 'event_2') обработать событие ever.t_2 else

endif

until fevent_narr.e = ' ' .

Рассмотрим пример из производственной системы, иллюст­рирующий использование механизма событий в базе данных со­вместно с правилами и процедурами. События используются для определения ситуации, когда рабочий инструмент нагревается до температуры свыше допустимой и должен быть отключен.

Создается правило, которое применяется всякий раз, когда новое значение температуры инструмента заносится в таблицу Инструмент. Как только оно превосходит 500 градусов, правило вызывает процедуру Отключить_кнструмент.

CREATE RULE Перегрев_:-:-:струмента AFTER UPDATE OF Инструмент (Температура)

WHERE Новое.Температура >= 5С0 EXECUTE PROCEDURE ОтключиЦЩ инструмент (Номер инструмента = Инструмент.Номер) ;

Создается процедура базы данных ®£ключить_инструмент, которая вызывает событие Перегрев; она будет выполнена в ре­зультате применения правила, определенного на шаге 1.

CREATE PROCEDURE Отключхть^инструмент (Номер_инструмента) AS BEGIN

UPDATE Инструмент

SET Статус = 'ЗЫКЛ'

WHERE Номер = Номер_у:нструмента;

RAISE D3EVENT Перегрев;

END;

Создается событие Перегрев, которое будет вызвано, когда инструмент перегреется:

CREATE DBEVENT Перегрев;

Наконец, создается прикладная программа Монитор^Инст- рументов, которая следит за состоянием инструментов. Она ре­гистрируется сервером в качестве получателя события Перегрев с помощью оператора register dbevent. Если событие про­изошло, программа посылает сообщение пользователю и сигнал, необходимый для отключения инструмента:

EXEC SQL REGISTER DBEVENT Перегрев;

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL (Имя события =

DBEVENTNAME, ...);

if (Имя события = 'Перегрев') then послать сообщение; отключить инструмент; endif.

Описанные выше конструкции в совокупности определяют логику работы (рис. 7.6).

Инструмент, код 3114

Рис. 7.6. Пример использования механизма событий в базе данных

Прикладная программа Монитор_Инструментов периодиче­ски регистрирует с помощью датчиков текущие значения пара­метров множества различных инструментов и заносит в табли­цу Инструмент новое значение температуры для данного инст­румента.

Всякий раз, когда это происходит, т. е. обновляется значение в столбце Температура таблицы Инструмент, применяется пра­вило Перегрев инструмента.

Применение правила состоит в проверке нового значения температуры. Если оно превышает максимально допустимое, то запускается процедура Отключить_кнструмент.

В том случае, когда используются традиционные методы оп­роса БД, логика работы была бы совершенно иной. Пришлось бы разработать дополнительную программу, которая периодиче­ски выполняла бы операцию выборки из таблицы Инструмент по критерию Температура > 5 0 0. Это очень сильно сказалось бы на эффективности, поскольку операция SELECT является ре­сурсоемкой. Разумеется, пример приведен лишь для иллюстра­ции схемы срабатывания механизма «правило — процедура — событие».

7.4. Схемы размещения и доступа к данным в распределенных БД

Размещение данных в распределенных БД характеризуется следующими понятиями:

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

• размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы доступа;

• репликация. Распределенная СУБД может поддержи­вать актуальную копию некоторого фрагмента на несколь­ких различных узлах.

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

Существуют четыре стратегии размещения данных в системе:

1. Централизованное размещение. Данная страте­гия предусматривает создание на одном из узлов единственной базы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети.

2. Фрагмент и рованное размещение. В этом случае база данных разбивается на непересекающиеся фрагменты, каж­дый из которых размещается на одном из узлов системы.

3. Р а з м е щ е н и е с полной репликацией. Эта страте­гия предусматривает размещение полной копии всей базы дан­ных на каждом из узлов системы. Стоимость устройств хранения данных и уровень затрат на передачу информации об обновле­ниях в этом случае также будут самыми высокими. Для преодо­ления части этих проблем в некоторых случаях используется технология снимков. Снимок представляет собой копию базы данных в определенный момент времени. Эти копии об­новляются через некоторый установленный интервал времени, например 1 раз в час или в сутки.

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

Управление параллельной обработкой в распределенных БД

При параллельной обработке данных (совместной работе не­скольких пользователей с общими данными) СУБД должна га­рантировать, что пользователи не будут мешать друг другу (сюда относятся, например, проблемы потерянного обновления, зави­симости от промежуточных результатов, несогласованности об­работки, несогласованности многих копий данных) и их дейст­вия будут изолированы. Такими единицами изолированности являются транзакции — неделимая (с точки зрения воздей­ствия на состояние целостности БД) последовательность опера­торов управления данными.

Решения по организации управления параллельным выпол­нением в распределенной среде основаны на подходах с ис­пользованием механизмов блокировок и временных отметок:

• механизм блокировки создает такие условия, что график параллельного выполнения транзакций будет эквивалентен некоторому (но, в обшем случае, непредсказуемому) вари­анту последовательного выполнения этих транзакций;

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

Механизм блокировки реализуется в виде следующих прото­колов двухфазной блокировки (2PL — two-phase lock):

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

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

3. При использовании распределенного протокола двухфазной блокировки диспетчеры блокировок размещены в каждом узле системы. Каждый отвечает за управление блокиров­кой данных, находящихся на его узле. Если данные не подверга­ются репликации, этот протокол функционирует аналогично протоколу двухфазной блокировки с первичными копиями. В противном случае распределенный протокол двухфазной бло­кировки использует особый протокол управления репликацией, получивший название «чтение одной копии и обновление всех копий». В этом случае для операций чтения может использовать­ся любая копия элемента, но прежде чем можно будет обновить значение элемента, должны быть установлены исключительные блокировки на всех копиях.

4. При использовании протокола блокировки боль­шинства копий диспетчер блокировок также имеется на ка­ждом из узлов системы, но. когда транзакции требуется считать или записать элемент данных, копии которого имеются на узлах системы, она должна отправить запрос на блокировку этого эле­мента более чем на половину из всех тех узлов, где имеются его копии. Транзакция не имеет права продолжать свое выполнение, пока не установит блокировки на большинстве копий элемента данных. Если ей не удастся это сделать за некоторый установ­ленный промежуток времени, она отменяет свои запросы и ин­формирует все узлы об отмене ее выполнения.

Двухфазные протоколы не могут устранить возможность вза­имной блокировки, поскольку при их использовании может воз­никнуть ситуации, когда некоторый узел остается заблокиро­ванным. Например, процесс, который обнаружил истечение тайм-аута после отправки своего согласия на фиксацию тран­закции, но так и не получил глобального подтверждения от ко­ординатора, остается заблокированным, если может взаимодей­ствовать только с узлами, которые также не имеют сведений о принятом глобальном решении. Неблокирующий прото­кол трехфазной фиксации транзакций не имеет пе­риода ожидания в состоянии неопределенности, в которое пере­ходят участники с момента подтверждения своего согласия на фиксацию транзакции и до момента получения от координатора извещения о глобальной фиксации или глобальном откате. В трехфазном протоколе между этапами голосования и приня­тия глобального решения вводится третий этап, называемый предфиксацией. После получения результатов голосования всех участников координатор рассылает глобальное сообщение precommit. Таким образом, участник, получивший глобальное извещение о предфиксации, знает, что все остальные участники проголосовали за фиксацию результатов транзакции и что со временем сам этот участник также выполнит фиксацию тран­закции, если не произойдет отказ. Датее каждый участник под­тверждает получение сообщения о предфиксации, и после чего координатор, получив все подтверждения, рассылает команду глобальной фиксации транзакции.

Многоуровневая модель предметной области для распределенных БД

Архитектурная модель ANSI/SPARC, представляющая собой классическое решение для локальных СУБД, может быть расши­рена на случай распределенных СУБД. На рис. 7.7 приведена обобщенная схема архитектуры распределенной БД, где в верх­ней части присутствуют схемы глобального уровня, обеспечи­вающие целостное представление БД, как если бы она была ло­кальной.

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

Рис. 7.7. Обобщенная схема распределенной БД

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

Технологии и средства удаленного доступа

Распределенные корпоративные приложения все более ус­ложняются, интегрируя в себя унаследованные приложения, раз­рабатываемые и вновь приобретаемые готовые программные средства. Кроме того, разные подсистемы решают разные биз­нес-задачи, однако одна из главных целей создания корпоратив­ной системы — получить «единый образ» общего состояния сис­темы, что обеспечит пользователям доступ к нужным ресурсам.

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

Промежуточное ПО эволюционировало вместе с архитекту­рой клиент — сервер. Ранние, но достаточно эффективные как с точки зрения разработки, так и эксплуатации, частные решения предназначались для упрощения доступа к базам данных в двух- звенной модели, где «толстый клиент» реализует всю логи­ку обработки информации, предоставляемой сервером базы дан­ных. Такие системы вполне удовлетворяли потребностям не­больших корпоративных подразделений с ограниченным числом пользователей и невысокой интенсивностью обмена.

Этот способ реализации клиент-серверной схемы доступа ог­раничивает возможности масштабирования, поскольку увеличе­ние числа обращений к одной базе данных значительно увели­чивает нагрузку на сервер и делает доступ к данным «узким ме­стом» в общей производительности системы. Кроме того, всякая модификация логики приложения требовала внесения измене­ний во все экземпляры клиентских приложений.

Чтобы избежать таких проблем, для разработки корпоратив­ных приложений используют трехзвенную модель, кото­рая переносит логику приложения на отдельный уровень сервера приложений. В результате клиентская часть приложения стано­вится «тоньше» и в основном отвечает за предоставление удоб­ного пользовательского интерфейса.

Развитие этого среднего звена клиент-серверной модели идет в сторону усложнения. Ограничиваясь вначале построением бо­лее высокого уровня абстракции для взаимодействия приложе­ния с ресурсами данных, разработчик приложения получал воз­можность использовать общие API (Application Program Inter­face), которые скрывали различия специфических интерфейсов коммуникационных протоколов более низкого уровня, напри­мер TCP/IP, Sockets или DECNet. Однако теперь этого уже явно недостаточно для построения сложных распределенных прило­жений. Современные решения не только обеспечивают межпро­граммное взаимодействие, но и являются платформой для реа­лизации сервера приложений, обеспечивая обширный набор не­обходимых служб: управления транзакциями, именования, защиты и т. д.

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

Таким образом, в распределенной неоднородной среде про­граммное обеспечение промежуточного уровня играет роль «ин­формационной шины», надстроенной над сетевым уровнем и обеспечивающей доступ приложения к разнородным ресурсам, а также независимую от платформ взаимосвязь различных при­кладных компонентов, изолирующую логику приложений от уровня сетевого взаимодействия и ОС.

ПО промежуточного уровня можно разделить на две кате­гории:

• доступа к базам данных (например, ODBC-интерфейсы и SQL-шлюзы);

• межмодульного взаимодействия — системы, реализующие вызов удаленных процедур (RPC — Remote Procedure Call), мониторы обработки транзакций (TP-мониторы), средства интеграции распределенных объектов.

При этом следует отметить, что различия прикладных задач не позволяют построить универсальное ПО, реализовав в одном продукте все необходимые возможности.

Двухзвенные клиент-серверные архитектуры

В простых двухзвенных моделях клиент — сервер, где не­сколько баз данных обслуживают ограниченное число пользова­телей настольных ПК, в роли встроенного ПО доступа к данным могут выступать обычные ODBC-драйверы.

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

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

Рассмотрим различные способы организации двухуровневого доступа прикладной программы к серверу базы данных в двух- звенной архитектуре.

Открытый интерфейс баз данных ODBC. Спецификация от­крытого интерфейса баз данных (ODBC — Open Database Connectivity) предназначена для унификации доступа к данным, размещенным на удаленных серверах. ODBC опирается на спе­цификации CLI.

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

В архитектуре ODBC используется один ODBC Driver Manager и несколько ODBC-драйверов, обеспечивающих доступ к конкретным СУБД. Driver Manager связывает приложение и интерфейсные объекты, которые выполняют обработку SQL-за­просов к конкретной СУБД (рис. 7.8).

Такой подход является достаточно универсальным, стандар­тизируемым, что и позволяет использовать ODBC-механизмы

Рис. 7.8. Структурная схема доступа к данным с использованием ODBC

для работы практически с любой системой, однако этот способ также не лишен недостатков:

• увеличивается время обработки запросов (как следствие введения дополнительного программного слоя);

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

Мобильный интерфейс к базам данных на платформе Java — JDBC (Java Data Base Connectivity) — это интерфейс прикладно­го программирования (API) для выполнения SQL-запросов к ба­зам данных из программ, написанных на платформенно-незави- симом языке Java, позволяющем создавать как самостоятельные приложения (standalone application), так и аплеты, встраиваемые в Web-страницы.

JDBC во многом подобен ODBC, он также построен на ос­нове спецификации CLI, однако имеет ряд следующих отличий;

• приложение загружает JDBC-драйвер динамически, следо­вательно, администрирование клиентов упрощается, более того, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места;

• JDBC, как и Java в целом, не привязан к конкретной аппа­ратной платформе, следовательно проблемы с переносимо­стью приложений практически снимаются;

• использование Java-приложений и связанной с ними идео­логии «тонких клиентов» обещает снизить требования к оборудованию клиентских рабочих мест.

Прикладные интерфейсы OLE DB и ADO. OLE DB (Object Linking and Embedding Data Base), как и ODBC — это приклад­ные интерфейсы доступа к данным с использованием SQL.

OLE DB специфицирует взаимодействие, обеспечивая еди­ный интерфейс доступа к данным через провайдеров — постав­щиков данных не только из реляционных БД. В отличие от ODBC, OLE DB предоставляет общее решение обеспечения СОМ-приложениям доступа к информации независимо от типа источника данных.

OLE DB включает два базовых компонента: провайдер дан­ных и потребитель данных. Потребитель (клиент) — это приложе­ние или СОМ-компонент, обращающийся посредством АР1-вы- зовов к OLE DB. Провайдер (сервер) — это приложение, отвечаю­щее на вызовы OLE DB и возвращающее запрашиваемый объект — обычно это данные в табличном виде.

ADO (Active Data Object) — это универсальный интерфейс высокого уровня к OLE DB. Модель объекта ADO не содержит таблиц, среды или машины БД. Здесь основными объектами яв­ляются следующие: объект Соединение, создающий связь с про­вайдером данных; объект Набор данных и объект Команда — выполнение процедуры, SQL-строки.

В общем случае ADO можно рассматривать как язык про­граммирования с БД, позволяющий выбирать, модифицировать и удалять записи. Поскольку он опирается на универсальный OLE DB, то может использоваться практически в любых прило­жениях Microsoft.

Взаимосвязь механизмов доступа к данным

Рассмотренные технологии построения приложения ориен­тированы на извлечение данных непосредственно из статическо­го источника (хранилища данных) и не могут обращаться за дан­ными к другому прикладному модулю.

Один из способов организации доступа к данным заключает­ся в непосредственном использовании API. Однако это означает полную зависимость создаваемого приложения от используемой СУБД. В этом случае переход к другой системе (например, для перехода от настольной системы к системе тина клиент — сер­вер) влечет за собой переписывание большей части программно­го кода клиентского приложения.

Таким образом, следующим этапом в обеспечении доступа клиентского приложения к данным является создание универ­сального механизма доступа к БД, обеспечивающего для клиент­ского приложения стандартный набор функций, классов или сервисов (служб), необходимых для работы с различными систе­мами управления базами данных. Эти стандартные функции (классы или сервисы) должны размешаться в библиотеках, име­нуемых драйверами или провайдерами баз данных (data base drivers (providers)). Каждая такая библиотека реализует набор стандартных функций, классов или сервисов, используя обраще­ния API к конкретной СУБД.

Наиболее популярными механизмами доступа к данным (Universal Data Access — UDA) в настоящий момент являются: ODBC, OLE DB, ADO, BDE.

Первые три являются фактически промышленными стандар­тами. Последний долгое время был единственным механизмом доступа к данным, реализованным в инструментальных средст­вах разработки компании Borland-Inprise (например, Delphi, С++ Builder).

На рис. 7.9 схематически представлены различные механиз­мы доступа к данным, включая непосредственные вызовы кли­ентской частью API системы управления базой данных.

Рис. 7.9. Взаимосвязь механизмов доступа к данным

Технологии межмодульного взаимодействия (трехуровневая архитектура)

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

На рис. 7.10 приведен обобщенный состав сервера приложе­ний с набором служб и средств связи с клиентскими системами и информационными ресурсами.

Рис. 7.10. Обобщенная структура сервера приложений

Спецификация вызова удаленных процедур. Протокол вызова удаленных процедур (Remote Procedure Calls — RPC) реализует асимметричное взаимодействие программных компо­нентов, когда можно выделить клиента, которому требуется не­которая услуга, и сервер, который такую услугу способен ока­зать, причем, как правило, клиент не может продолжать свое выполнение, пока сервер не произведет требуемые от него дей­ствия. С точки зрения клиентской программы обращение к сер­веру ничем не отличается от вызова локальной процедуры.

Средства вызова удаленных процедур (RPC) поддерживают синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером).

Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным процедурам — клиентскому и серверному суррогатам (client stub и server stub). Эти процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодейст­вия удаленных прикладных модулей.

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

Ключевым компонентом RPC является язык описания интерфейсов (interface definition language — IDL), предна­значенный для определения интерфейсов, которые задают кон­трактные отношения между клиентом и сервером. Интерфейс содержит определение имени функции и полное описание пере­даваемых параметров и результатов выполнения.

Язык IDL обеспечивает независимость механизма RPC от языков программирования — вызывая удаленную процедуру, клиент может использовать свои языковые конструкции, кото­рые IDL-компилятор преобразует в свои описания. На сервере IDL-описания обратно преобразуются в конструкции языка про­граммирования. на котором реализован серверный процесс.

Транзакции в распределенных БД

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

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

В современных СУБД предусмотрен так называемый прото­кол двухфазовой (или двухфазной) фиксации транзакций (two-phase commit).

Фаза 1 начинается, когда при обработке транзакции встре­тился оператор commit. Сервер распределенной БД (или компо­нент СУБД, отвечающий за обработку распределенных транзак­ций) направляет уведомление «подготовиться к фиксации» всем серверам локальных БД, выполняющим распределенную тран­закцию. Если все серверы приготовились к фиксации (т. е. от­кликнулись на уведомление и отклик был получен), сервер рас­пределенной БД принимает решение о фиксации. Серверы ло­кальных БД остаются в состоянии готовности и ожидают от него команды «зафиксировать». Если хотя бы один из серверов не откликнулся на уведомление в силу каких-либо причин, будь то аппаратная или программная ошибка, то сервер распределен­ной БД откатывает локальные транзакции на всех узлах, вклю­чая даже те, которые подготовились к фиксации и оповестили его об этом.

Фаза 2 — сервер распределенной БД направляет команду «зафиксировать» всем узлам, затронутым транзакцией, и гаран­тирует, что транзакции на них будут зафиксированы. Если связь с локальной базой данных потеряна в интервал времени между моментом, когда сервер распределенной БД принимает решение о фиксации транзакции, и моментом, когда сервер локальной БД подчиняется его команде, то сервер распределенной БД про­должает попытки завершить транзакцию, пока связь не будет восстановлена.

Мониторы обработки транзакций. Мониторы обработки транзакций (Transaction Processing Monitor — ТРМ), или мони­торы транзакций — это программные системы (которые относят к категории middleware, т. е. к посредническому или промежуточному ПО), решающие задачу эффективного управле­ния информационно-вычислительными ресурсами в распреде­ленной системе.

Первоначатьно основной задачей ТРМ в среде клиент—сер­вер было сокращение числа соединений клиентских систем с ба­зами данных. При непосредственном обращении клиента к сер­веру базы данных для каждого клиента устанавливается соедине­ние с СУБД, которое порождает запуск отдельного процесса в рамках операционной системы. TP-мониторы брали на себя роль концентратора таких соединений, становясь посредником между клиентом и сервером базы данных. Основное назначение TP-мониторов — автоматизированная поддержка приложений, представленных в виде последовательности транзакций.

Одна из основных функций ТРМ — обеспечение быстрой обработки запросов, поступающих к серверу приложений от множества клиентов (от сотен до тысяч). ТРМ выполняет ее, мультиплексируя запросы на обслуживание, направляя их серве­рам приложения, число которых контролируется им самим.

Важнейшая характеристика ТРМ — поддержка многомашин­ных конфигураций с возможностью миграции серверов прило­жений и их групп на резервный компьютер в случае сбоев в ра­боте основного — является фундаментом, на котором может быть построена система, по надежности близкая к абсолютной. Действительно, применение так называемых безотказных (fault tolerant) компьютеров гарантирует сохранение работоспособно­сти лишь при случайных сбоях, но бессильно перед злоумыш­ленником или в случае механического повреждения.

На современном рынке мониторов транзакций основными являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc), TUXEDO Sytem (Novell). Наиболее известной из этой группы является система CICS (Customer Information Control System), работавшая на мэйнфрейме IBM.

Модель обработки транзакций. Понятия транзакции в ТРМ и в традиционных СУБД значительно отличаются. Суть остается одной, но в понимании СУБД транзакция — это атомарное дей­ствие над базой данных, в то время как в ТРМ транзакция трак­туется гораздо шире. Она включает не только операции с данны­ми, но и любые другие действия — передачу сообщений, выдачу отчетов, запись в индексированные файлы, опрос датчиков и т. д. Это позволяет реализовать в 1 I'M прикладные транзак­ции, бизнес-транзакции, которые в СУБД не предусмотрены.

ТРМ опирается на модель обработки распределенных тран­закций X/Open DTP, которая описывает взаимодействие трех субъектов обработки транзакций — прикладной программы (в качестве прикладной программы фигурирует как сервер прило­жения, так и клиент приложения), менеджера транзакций (Transaction Manager — ТМ) и менеджера ресурсов (Resource Manager — RM). Модель представлена на рис. 7.11.

Рис. 7.11. Модель обработки распределенных транзакций X/Open DTP

На RM возложено управление информационными ресурса­ми — будь то файлы, базы данных или что-то другое. Прило­жение взаимодействует с RM либо с помощью набора специ­альных функций, либо (если в качестве RM выступает реляци­онная SQL-ориентированная СУБД) посредством операторов языка SQL, инициируя необходимые операции с данными. По­следние оформляются как транзакции, обработку которых бе­рет на себя ТМ. Если с помощью монитора транзакций необ­ходимо решать задачи обработки распределенных транзакций, то роль менеджера ресурсов должна играть СУБД, поддержи­вающая двухфазовый протокол фиксации транзакций и удовле­творяющая стандарту X/Open ХА (например, Oracle 7.x, OpenlNGRES, Informix-Online 7.x).

Роль ТМ в модели X/Open DTP — это роль диспетчера, глав­ного координатора транзакций. Он обладает полным набором функций управления как локальными, так и глобальными рас­пределенными транзакциями. В последнем случае транзакция может обновлять данные на нескольких узлах, причем управле­ние данными на них, вообще говоря, осуществляется различны­ми RM. Обработка распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации тран­закций, который гарантирует целостность данных в информаци­онной системе, распределенной по нескольким узлам, независи­мо от того, какой RM управляет обработкой данных на каждом таком узле. Эта уникальная возможность как раз и позволяет рассматривать ТРМ как средство интеграции в гетерогенной ин­формационной среде.

Функции ТМ в модели X/Open DTP не ограничиваются только управлением транзакциями. Он берет на себя также ко­ординацию взаимодействия клиента и сервера (поэтому иногда его называют менеджером транзакций и коммуникаций). При этом используется высокоуровневый интерфейс ATMI, пред­ставляющий собой набор вызовов функций на языке третьего поколения (например, на языке Си). С его помощью разработ­чик реализует один из нескольких режимов взаимодействия кли­ента и сервера в рамках расширенной модели «клиент — сер­вер». Ни сервер приложения, ни клиент приложения не содер­жат явных вызовов менеджера транзакций — они включены в библиотечные функции ATMI и «невидимы» извне. Таким обра­зом, детали взаимодействия прикладной программы и монитора транзакций скрыты от разработчика, что и дает основание гово­рить об ATMI как о высокоуровневом интерфейсе.

Функциональный подход. Фундаментальная характеристика ТРМ — функциональный (function-centric) подход к проектиро­ванию бизнес-приложений — сосредоточение всех прикладных функций в серверах приложений по сути означает поставку (или предоставление) функций (functions shipping) для программы-клиента, в отличие от традиционной архитектуры с сервером базы данных, следующей парадигме поставка (или предоставление) данных (data shipping).

Возможность декомпозиции приложений по нескольким уровням с четко очерченными функциями и стандартными ин­терфейсами позволяет создавать легко модифицируемые систе­мы со стройной и целостной архитектурой. Концентрация чисто прикладных функций в серверах приложений и использование унифицированных интерфейсов с другими логическими компо­нентами делает прикладную систему практически полностью не­зависимой как от конкретной реализации интерфейса с пользо­вателем, так и от необходимого ей менеджера ресурсов. Первое означает, что для реализации интерфейса с пользователем может быть выбран практически любой удобный и привычный для раз­работчика инструментарий, будь то Microsoft Visual С++ или Visual Basic; следствием второго является то, что менеджер ре­сурсов (например, СУБД) может быть заменен на другой, под­держивающий тот же стандарт интерфейса с прикладной про­граммой. Для реляционных СУБД в качестве унифицированного интерфейса используется встроенный (embedded) SQL. Разуме­ется, в реализации ESQL для каждой конкретной СУБД имеются различия, порой весьма существенные. Поэтому приложение должно быть либо разработано специально с целью работы с конкретной СУБД, либо оно должно быть спроектировано так, чтобы максимально безболезненно перенастраиваться на работу с другой СУБД.

Функциональный подход имеет своим следствием и преиму­щества администрирования приложения. Отныне оно рассмат­ривается как единое целое; сервер приложения имеет набор па­раметров, устанавливаемых его администратором; как и сервер БД, сервер приложения запускается и останавливается специ­альными командами; существуют команды, позволяющие опро­сить параметры сервера приложения и вывести их на консоль.

Таким образом снимается одно из серьезных ограничений производительности и масштабируемости клиент-серверной сре­ды — необходимость поддержки отдельного соединения с базой данных для каждого клиента.

7.5. Объектно-ориентированные технологии распределенной обработки

Сегодня наибольшее применение для разработок приложе­ний распределенной обработки находят две компонентные модели — DCOM и CORBA. Эти технологии реатизуют трех­уровневую архитектуру модели «клиент — сервер». Введение специального промежуточного слоя — сервера приложений, ко­торому «делегированы полномочия» организации взаимодейст­вия клиента и сервера, обеспечивает возможность интеграции объектов, размещенных на машинах разных платформ и под управление разнотипных операционных систем.

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

Основу этого подхода составляет «минимальная» объектная модель, обладающая ограниченными возможностями, но имею­щая обязательные аналоги в наиболее распространенных объ­ектных системах. В архитектуре CORBA используется модель Core Object Model с соответствующим языком спецификации интерфейсов объектов (Interface Definition Language — IDL). Чтобы обеспечить возможность взаимодействия объекта, суще­ствующего в одной системе программирования, с некоторым объектом из другой системы программирования, в исходный текст первого объекта (объявления его класса) должна быть по­мещена IDL-спецификация интерфейса (имя метода, список имен и типов данных входных и выходных параметров) того объекта, метод которого должен быть вызван. Аналогичная спе­цификация должна быть помещена на стороне вызываемого объекта. Далее, спецификации, транслированные IDL-процес- сором в выражения языка программирования, включаются в ис­ходный текст программы на языках Си, Java.

В DCOM-технологии, представленной на рис. 7.12, взаимо­действие между клиентом и сервером осуществляется через двух посредников. Клиент помещает параметры вызова в стек и обра­щается к методу интерфейса объекта. Это обращение перехваты­вает посредник Proxy, упаковывает параметры вызова в СОМ-пакет и адресует его в Stub, который в свою очередь рас­паковывает параметры в стек и инициирует выполнение метода объекта в пространстве сервера. При этом объект должен быть предварительно зарегистрирован на локальной машине, чтобы клиент с помощью распределенной службы имен (в качестве ко-

Рис. 7.12. DCOM-технология взаимодействия «клиент — сервер»

торой Microsoft предлагает Active Directory) мог его отыскать по глобальному уникальному идентификатору (GUId).

CORBA-технология также использует интерфейс объекта, но в этом случае схема взаимодействия объектов (рис. 7.13) включа­ет промежуточное звено (Smart agent), реализующее доступ к уда­ленным объектам. Smart agent, установленный на машинах сете­вого окружения (сервере локальной сети или Internet-узле), мо­делирует сетевой каталог известных ему серверов объектов. Регистрация объектов сервера в каталоге одного или нескольких Smart agent'oB происходит автоматически при создании сервера.

Рис. 7.13. CORBA-технология взаимодействия «клиент — сервер»

Связи между брокерами осуществляются в соответствии с требованиями специального протокола General Inter ORB Protocol, определяющего низкоуровневое представление данных и множество форматов сообщений.

На машине клиента создаются два объекта-посредника: Stab (заглушка) и ORB (Object Required Broker — брокер вызываемого объекта). Так же как и в DCOM-технологии, Stub передает пере­хваченный вызов брокеру, который посылает широковещатель­ное сообщение в сеть. Smart agent, получив сообщение, отыскива­ет сетевой адрес сервера и передает запрос брокеру, размещенно­му на машине сервера. Вызов требуемого объекта производится через специальный базовый объектный адаптер (BOA). При этом данные в стек пространства вызываемого объекта помещает осо­бый объект сервера (Skeleton — каркас), который вызывается адаптером.

CORBA имеет два механизма реализации запросов к объ­ектам:

• статический, предполагающий использование заглушек и каркасов, интерфейсы которых были сгенерированы при создании объекта;

• динамический вызов с помощью интерфейса динамическо­го вызова (DII).

Интерфейс динамического вызова позволяет определять объ­екты и их интерфейсы во время выполнения, а затем формиро­вать заглушки. Аналогично, на стороне сервера может использо­ваться динамический интерфейс каркасов (DSI), что позволяет обращаться к реализации объекта, для которого на этапе созда­ния не был сформирован каркас.

Ключевым компонентом архитектуры CORBA является язык описания интерфейсов IDL, на уровне которого поддерживают­ся «контрактные» отношения между клиентом и сервером и обеспечивается независимость от конкретного объектно-ориен­тированного языка. CORBA IDL поддерживает основные поня­тия объектно-ориентированной парадигмы (инкапсуляцию, по­лиморфизм и наследование). При этом CORBA-объекты могут быть преобразованы в объекты языков программирования (на­пример, Java, С, С++), т. е. будут сформированы файлы:

• исходного клиентского кода, содержащего интерфейсные заглушки;

• исходного серверного кода, содержащего каркасы;

• заголовков, которые включаются в клиентскую и сервер­ную программы.

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

Как DCOM, так и CORBA, в отличие от процедурного RPC, дают возможность динамического связывания удаленных объек­тов: клиент может обратиться к серверу-объекту во время вы­полнения, не имея информации об этом объекте на этапе ком­пиляции. В CORBA для этого существует специальный интер­фейс динамического вызова DII. а СОМ использует механизм OLE-Automation. Информацию о доступных объектах сервера на этапе выполнения клиентская часть программы получает из спе­циального хранилища метаданных об объектах — репозитария интерфейсов Interface Repositary в случае CORBA, или библиоте­ки типов (Type Library) в модели DCOM. Эта возможность очень важна для больших распределенных приложений, поскольку по­зволяет менять и расширять функциональность серверов, не внося существенных изменений в коя клиентских компонентов программы. Например, банковское приложение, основная биз­нес-логика которого поддерживается сервером в центральном офисе, а клиентские системы — в филиалах, размещенных в раз­ных городах.

Контрольные вопросы

1. Какие разновидности систем «клиент — сервер» вы знаете?

2. Что такое файловый сервер?

3. Что такое сервер баз данных?

4. Что такое сервер приложений?

5. Сформулируйте основные требования к системам управления рас­пределенными базами данных.

6. Перечислите основные условия и предпосылки появления систем управления распределенными базами данных.

7. Перечислите основные различия системы распределенной обработки данных и системы распределенных баз данных.

8. Обоснуйте целесообразность разделения «клиентских» и «сервер­ных» функций.

9. Проведите сравнительный анализ распределения функций для различ­ных базовых архитектур.

10. Определите основные принципы и примерные структурные схемы сервера распределенной обработки.

11. Перечислите основные решения распределенной обработки на основе межмодульного взаимодействия.