5.3.15. Распределенные вычисления (рв)

Различают режимы удаленного узла и дистанционного управления (рис. 5.9).

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

Рис. 5.9. Удаленный узел и дистанционное управление

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

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

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

• сервер баз данных (DBS - Data Base Server);

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

Рис. 5.10. Варианты распределенных вычислений

FS - основная модель для ЛВС на персональных ЭВМ. В случае ее использования возникает проблема корректного обновления файлов. Все процессы клиентов и серверов имеют маркеры, содержащие имя файла и маску, в которой указаны права: только чтение атрибутов файла, только чтение самого файла, открытие файла, модификация файла, стирание. Все обращения идут через менеджер маркеров, который отслеживает соблюдение ограничений и разрешает конфликты одновременного обращения для чтения и обновления файлов. Недостаток FS - перегрузка сети из-за необходимости пересылать файлы полностью.

Положительные стороны RDA: уменьшение трафика, унификация интерфейса с сервером на базе языка SQL.

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

ApS - модель, известная также под названием "трехзвенная схема", или "монитор транзакций". В ней длинные связи имеют место как между терминалом пользователя и приложением, так и между приложением и СУБД (рис. 5.11).

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

Рис. 5.11. Трехзвенная схема распределенных вычислений

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

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

Рис. 5.12. Оповещение прикладных программ о событиях в БД

Для реализации многопротокольности разрабатываются специальные технологии. Наиболее известной среди них является технология ODBC (Open Data Base Connectivity) фирмы Microsoft. Фактически ODBC представляет собой библиотеку функций для обращений прикладных программ (ПП) к различным СУБД на основе языка SQL. Из ПП обращение происходит к виртуальной СУБД, в которой с помощью драйверов осуществляется переход к реальной СУБД.

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