2.1.8.6. Распределенная обработка приложений

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

Три параметра организации работы приложений в сети:

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

• выделение в сети специализированных серверов для выполнения некоторых общих функций;

• способ взаимодействия между частями приложений, выполняющихся на разных ЭВМ.

Разделение приложений на части. Хотя возможны различные варианты разделения приложений, существуют типовые схемы. Можно выделить 6 частей:

• средства представления данных на экране;

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

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

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

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

• файловые операции (стандартные операции над файлами и файловой системой, обычно операции ОС).

Двухзвенные схемы. На рис. 147 представлены три варианта двухзвенных схем. Все три варианта соответствуют технологии «клиент-сервер».

В первом варианте (см. рис. 147, а) клиент работает как терминал. Эту модель в последнее время стали называть «тонкий клиент». Второй вариант – «клиент-сервер» или «сервер БД» (см. рис. 147, б). Третий вариант – «толстый клиент» (см. рис. 147, в). В табл. 21 приведено сравнение первого и третьего вариантов.

Рис. 147. Варианты построения двухзвенных систем

Таблица 21

Сравнение вариантов построения двухзвенных систем

Схема	Преимущества	Недостатки
Тонкий клиент	Проще администрирование	Недостаточная масштабируемость и отказоустойчивость
Файл-сервер	Хорошая масштабируемость	Компьютер клиента должен иметь высокую производительность. Возрастает нагрузка на сеть

Трехзвенная схема. Трехзвенная схема (рис. 148) позволяет лучше сбалансировать нагрузку на сеть. Появляется возможность дальнейшей специализации серверов и средств разработки распределенных приложений.

Рис. 148. Построение трехзвенной системы

Пример. Приведем возможный вариант состава трехзвенной схемы:

• Клиент: ОС Windows 95/98;

• Сервер приложений: сервер приложений и монитор транзакций TUXEDO в среде Solaris на компьютерах Sun Microsystems;

• Сервер БД: сервер БД Oracle в среде Windows 2000 на компьютерах компании Compaq.

Монитор транзакций (не входит в состав сетевой ОС) управляет транзакциями с БД и поддерживает целостность распределенных приложений.

Трехзвенные схемы часто применяются как средства класса middleware для реализации в сети общих для распределенных приложений функций:

– средства асинхронной обработки сообщений (message-oriented middleware);

– средства удаленного вызова процедур RPC (Remote Procedure Call);

– брокеры запроса объектов ORB (Object Request Broker), которые находят объекты, хранящиеся на различных компьютерах, и помогают их использовать в одном приложении.

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

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

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

Сообщение – это блок информации, отформатированный процессом-отправителем так, чтобы он был понятен процессу получателю.

Клиент посылает сообщение-запрос, сервер реагирует сообщением-ответом. Сообщение состоит из заголовка фиксированной длины и набора данных определенного типа (переменной длины).

Заголовок содержит:

– адрес, однозначно определяющий отправляющий и принимающий процессы;

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

– поле типа данных (символьные, числовые);

– поле длины данных (байты).

Процессы взаимодействуют посредством примитивов send и receive, которые воспринимает система передачи сообщений – это транспортная система ОС. На рис. 149 представлена схема компонентов сетевого ПО, участвующих во взаимодействии процессов. На основе примитивов send и receive строится, например, распределенная файловая система или служба удаленного вызова процедур (RPC), которые, в свою очередь, служат основой для работы других сетевых служб.

Рис. 149. Схема компонентов сетевого ПО, участвующих во взаимодействии процессов

Синхронизация процессов обмена сообщениями определяется типом примитивов send и receive, которые могут быть блокирующими (рис. 150, а) и неблокирующими (рис. 150, б).

Рис. 150. Типы примитивов: блокирующие (а) и неблокирующие (б)

При использовании блокирующего примитива send процесс-отправитель приостанавливается до получения сообщения-подтверждения от процесса получателя. При использовании блокирующих примитивов возможен клинч (clinch, смертельное объятие), если сообщение утеряно или процесс-получатель потерпел крах. Для устранения возможного клинча используется механизм тайм-аута. При использовании неблокирующих примитивов send и receive управление возвращается вызывающему процессу немедленно после того, как ядро ОС получает информацию о том, где находится буфер для приема или передачи данных. Если оба примитива send и receive блокирующие, то процессы взаимодействуют синхронно. В противном случае процессы взаимодействую асинхронно.

Вызов удаленных процедур. Вызов удаленных процедур (Remote Procedure Call – RPC) – это надстройка над системой обмена сообщениями в ОС, которая служит для организации распределенных вычислений. Благодаря такой надстройке, механизм передачи управления и данных внутри программы, выполняющейся на одной машине, распространяется на передачу управления и данных через сеть.

Впервые RPC реализован компанией Sun Microsystems, выдвинувшей принцип «сеть – это компьютер». Механизм RPC эффективен, если передается относительно малое количество данных, время ответа невелико, а вычисление ответа трудоемко.

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

– выполняются на разных машинах и, следовательно, имеют разные адресные пространства;

– обязательно используют нижележащую систему обмена сообщениями (но это обстоятельство должно быть скрыто от пользователя).

В реализации RPC участвуют, как минимум, два процесса – по одному на каждой машине.

Возможны ситуации:

– при аварии вызывающей процедуры удаленно вызванные процедуры становятся «осиротевшими»;

– при аварийном завершении удаленной процедуры появляется «обездоленный родитель».

Вызов локальной процедуры может выглядеть, например, так:

m=my_write(fd, buf, length),

где fd – дескриптор файла, buf – указатель на массив символов, length – длина массива. В случае локальных процедур параметры могут вызываться как по ссылке (by name), так и по значению (by value). При реализации удаленных процедур возможен только один вариант – передача параметров по значению.

Вызов удаленной процедуры должен выглядеть, по возможности, так же, как вызов локальной процедуры. Для этого в библиотеку процедур помещается другая версия процедуры – стаб (stub – заглушка). На удаленном компьютере (т.е. в сервере) помещается серверный стаб (см. рис. 151).

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

Существуют два варианта генерации стабов:

– вручную;

– автоматически (используется язык определения интерфейсов – Interface definition Language = IDL).

Связывание клиента с RPC-сервером может осуществляться одним из способов:

• в широковещательном режиме;

• с использованием централизованного агента связывания.

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

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

Рис. 151. Размещение стаба на удаленном компьютере

Мобильный агент – это программа, которая может перемещаться от одной сетевой машины к другой, выбирая самостоятельно время и место перемещения. При перемещении состояние мобильного агента запоминается и переносится на новую машину, что позволяет продолжить работу агента. Применение мобильных агентов реализует идею удаленного программирования (Remote Programming, RP). Клиент создает процедуру, которая способна выполнить требуемую работу на удаленной машине. Затем клиент передает эту процедуру для выполнения на удаленной машине (сервере).

Преимущества использования мобильных агентов:

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

2. Расширяется функциональность сервера, поскольку серверные компоненты приложения, использующего мобильные агенты, динамически инсталлируются агентами. При использовании через RPC серверные компоненты приложения должны быть статически инсталлированы.

Например, чтобы стереть N файлов на удаленной машине с помощью RPC, клиенту требуется сделать N+1 вызовов и получить N+1 сообщений (один вызов и одно сообщение для получения сведений о файлах). При использовании мобильного агента достаточно переслать на удаленную машину агента (процедуру удаления и признаки, по которым удаляются файлы) и после выполнения работы агентом получить соответствующее сообщение.

Другой пример – мобильные вычисления, когда клиент подсоединяется по низкоскоростному каналу к постоянной сети на короткий промежуток времени с мобильной платформы, отправляет агента для выполнения задачи и отсоединяется, а затем через некоторый промежуток времени подсоединяется к другой точке сети и забирает результаты работы агента.

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

Рассмотрим некоторые понятия технологии CORBA (Context Broker Architecture), связанные с обеспечением интероперабельности между различными агентскими системами. Агентская система – это платформа, способная создавать, интерпретировать, запускать, перемещать и уничтожать агенты. Агентская система с полномочиями конкретного пользователя реализует политику безопасности этого пользователя. Местоположением агента является адрес места – место (place) (рис. 152), которое находится внутри агентской системы. Все общение между агентскими системами (рис. 153) происходит через коммуникационную инфраструктуру (КИ). Коммуникационная инфраструктура обеспечивает транспортные службы связи (например, RPC), службу имен и службу безопасности для агентских систем.

Рис. 152. Местоположение агента.

Рис. 153. Общение между агентскими системами.