Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

3.4. Перенос кода 191

ный подход к построению распределенных приложений состоит в разбиении

приложения на части с последующим определением, где какая часть будет

выполняться. Подобный подход, например, использовался в различных много-

звенных приложениях клиент-сервер, обсуждавшихся в главе 1.

Однако, если код можно переносить с машины на машину, становится воз-

можным конфигурировать распределенные системы динамически. Например,

рассмотрим сервер, реализующий стандартизованный интерфейс к файловой

системе. Чтобы предоставить удаленному клиенту доступ к файловой системе,

сервер использует специальный протокол. В обычном варианте клиентская реа-

лизация интерфейса с файловой системой, основанная на этом протоколе, долж-

на быть скомпонована с приложением клиента. Этот подход предполагает, что

подобное программное обеспечение для клиента должно быть доступно уже то-

гда, когда создается клиентское приложение.

Альтернативой является предоставление сервером клиенту реализации не ра-

нее,

чем это будет действительно необходимо, то есть в момент привязки клиен-

та к серверу. В этот момент клиент динамически загружает реализацию, произ-

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

Схема такого пути показана на рис. 3.8. Подобная модель динамически перено-

симого из удаленного хранилища кода требует стандартизации протокола за-

грузки и инициализации кода. Кроме того, необходимо, чтобы загружаемый код

можно было выполнять на машине клиента. Различные решения этой проблемы

будут рассмотрены ниже и в последующих главах.

Клиент

Взаимодействие

клиента и сервера

Сервер

Соответствующий

службе клиентский

код

Извлечение кода клиентом

Хранилище кода

Рис. 3.8. Принцип динамического конфигурирования клиента

для

связи с сервером.

Сначала клиент извлекает необходимое программное обеспечение,

а затем обращается к серверу

Важное преимущество подобной модели динамической дозагрузки клиент-

ского программного обеспечения состоит в том, что клиенту для общения с серве-

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

мого программного обеспечения. Вместо этого при необходимости программы

могут быть перенесены на клиента и точно так же удалены, когда необходимость

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

стандартизованы, то мы можем менять протокол взаимодействия клиент-сервер

и его реализацию так часто, как пожелаем. Изменения не окажут влияния на су-

192 Глава 3. Процессы

шествующие клиентские приложения, связанные с сервером. Существуют, разу-

меется, и недостатки. Наиболее серьезный, который мы будем обсуждать в гла-

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

только объявленные интерфейсы доступа к вашему незащищенному жесткому

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

—

не

всегда оправдано.

Модели переноса кода

Хотя перенос кода подразумевает только перемещение кода с машины на маши-

ну, этот термин имеет более широкую область применения. Традиционно связь

в распределенных системах основана на обмене данных между процессами. Пере-

нос кода в широком смысле связан с переносом программ с машины на машину

с целью исполнения этих программ в нужном месте. В некоторых случаях, таких

как перенос процессов, также должны переноситься состояние программы, полу-

чаемые сигналы и прочие элементы среды.

Для лучшего понимания различных моделей переноса кода используем шаб-

лон, описанный в

[156].

Согласно этому шаблону, процесс состоит из трех сег-

ментов.

Сегмент

кода — это часть, содержащая набор инструкций, которые вы-

полняются в ходе исполнения программы.

Сегмент ресурсов

содержит ссылки на

внешние ресурсы, необходимые процессу, такие как файлы, принтеры, устройст-

ва, другие процессы и т. п. И наконец,

сегмент исполнения

используется для хра-

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

программы.

Абсолютный минимум для переноса кода предлагает модель

слабой

мобильно-

сти {weak mobility). Согласно этой модели допускается перенос только сегмента

кода, возможно вместе с некоторыми данными инициализации. Характерной

чертой слабой мобильности является то, что перенесенная программа всегда за-

пускается из своего исходного состояния. Это происходит, например, с Java-an-

плетами. Достоинство подобного подхода в его простоте. Слабая мобильность

требуется только для того, чтобы мaшpп^a, на которую переносится код, была в

состоянии его исполнять. Этого вполне достаточно, чтобы сделать код переноси-

мым. Мы вернемся к данному вопросу, когда будем обсуждать перенос программ

в гетерогенных системах.

В противоположность слабой мобильности, в системах, поддерживающих

сильную мобильность {strong

mobility),

переносится также и сегмент исполнения.

Характерная черта сильной мобильности

—

то, что работающий процесс может

быть приостановлен, перенесен на другую машину и его выполнение продолжено

с того места, на котором оно было приостановлено. Ясно, что сильная мобиль-

ность значительно мощнее слабой, но и значительно сложнее в реализации. Приме-

ром системы, поддерживающей сильную мобильность,

является

система D'Agents,

которую мы рассмотрим позднее в этой главе.

Независимо от того, является мобильность слабой или сильной, следует про-

вести разделение на системы с переносом, инициированным отправителем, и сис-

темы с переносом, инициированным получателем. При переносе, инициирован-

ном

отправителем,

перенос инициируется машиной, на которой переносимый

3.4. Перенос кода 193

код постоянно размещен или выполняется. Обычно перенос, инициированный

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

Другой пример

—

передача поисковых программ через Интернет на сервер баз

данных в Web для выполнения запроса на этом сервере. При переносе, иници-

ированном

получателем,

инициатива в переносе кода принадлежит машине-по-

лучателю. Пример такого подхода

—

Java-апплеты.

Перенос, инициируемый получателем, обычно реализуется проще. Во многих

случаях перенос кода происходит между клиентом и сервером, причем инициа-

тива исходит от клиента. Безопасный перенос кода на сервер, как это происхо-

дит при переносе, инициированном отправителем, часто требует, чтобы клиент

был сначала зарегистрирован и опознавался сервером. Другими словами, сервер

должен знать всех своих клиентов, поскольку клиенты, естественно, имеют до-

ступ к ресурсам сервера, таким как его диск. Защита этих ресурсов является не-

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

вания этого процесса принимающей стороной может осуществляться анонимно.

Более того, сервер обычно не заинтересован в ресурсах клиента. Напротив, пере-

нос кода на клиента производится исключительно с целью увеличения произво-

дительности клиента. С этой стороны в защите нуждается лишь небольшое

количество ресурсов, таких как память и сетевое соединение. Мы вернемся к за-

щите переноса кода позже и подробно рассмотрим ее в главе 8.

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

несенный код выполняется в процессе-приемнике или когда он выполняется

в новом, специально запущенном процессе. Так, например, Java-апплеты просто

загружаются в web-браузер и выполняются в адресном пространстве браузера.

Преимущество этого подхода состоит в том, что нам нет необходимости запус-

кать новый процесс

разрывать из-за этого связь с машиной-приемником. Ос-

новной недостаток состоит в том, что процесс-приемник приходится защищать

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

—

потре-

бовать от операционной системы для перемещенного кода создать отдельный

процесс. Отметим, что, как уже говорилось, это решение не решает проблем с до-

ступом к ресурсам.

Помимо переноса работающего процесса, называемого также миграцией про-

цесса, сильная мобильность может также осуществляться за счет удаленного

клонирования. В отличие от миграции процесса клонирование создает точную

копию исходного процесса, которая выполняется на удаленной машине. Клон

процесса выполняется параллельно оригиналу. В UNIX-системах удаленное кло-

нирование имеет место при ответвлениях дочернего процесса в том случае, когда

этот дочерний процесс продолжает выполнение на удаленной машине. Преиму-

щество клонирования

—

в схожести со стандартными процедурами, осуществляе-

мыми в многочисленных приложениях. Единственная разница между ними со-

стоит в том, что клонированный процесс выполняется на другой машине. С этой

точки зрения миграция путем клонирования

—

самый простой способ повыше-

ния прозрачности распределения.

Различные варианты переноса кода иллюстрирует рис. 3.9.

194 Глава 3. Процессы

/Слабая мобильность.

Механизм переноса

^Сильная мобильность.

Перенос,

' инициируемый

отправителем

Перенос,

' инициируемый

получателем

Перенос,

' инициируемый

отправителем

Перенос,

' инициируемый

получателем

Исполнение

в процессе-приемнике

Исполнение

в отдельном процессе

. Исполнение

в процессе-приемнике

. Исполнение

в отдельном процессе

' Перенос процесса

' Клонирование процесса

' Перенос процесса

Клонирование процесса

Рис. 3.9. Варианты переноса кода

3.4.2. Перенос и локальные ресурсы

Ранее мы рассматривали перенос только сегментов кода и исполнения. Сегмент

ресурсов требует отдельного рассмотрения. Перенос кода нередко сильно затруд-

няет

то,

что сегмент ресурсов не всегда можно перенести с такой же легкостью без

изменений, как другие сегменты. Так, например, рассмотрим процесс, содержа-

щрш ссылку на конкретный порт TCP, посредством которого он взаимодействует

с другими (удаленными) процессами. Эта ссылка находится в сегменте ресурсов

процесса. При переносе процесса на другую машину процесс должен освободить

занятый им порт и запросить другой

—

на той машине, на которую он был пере-

мещен. В других случаях перенос ссылки проблем не создает. Например, ссылка

на файл с использованием абсолютного URL-адреса останется верной независи-

мо от

того,

на какой машине выполняется процесс, содержащий этот URL-адрес.

Чтобы понять, какое влияние оказывает перенос кода на сегмент ресурсов,

было выделено три типа связи процесса с ресурсами

[156].

Наиболее сильная

связь наблюдается, когда процесс ссылается на ресурс по его идентификатору.

В этом случае процесс требует в точности тот ресурс, на который ссылается. При-

мером подобной привязки по идентификатору {binding by identifier) является

использование процессом URL-адреса для ссылки на конкретный web-сайт или

Интернет-адреса для ссылки на FTP-сервер. По этим же причинам ссылка на ло-

кальную конечную точку взаимодействия также будет считаться привязкой по

идентификатору.

Более слабая связь процесса с ресурсами будет иметь место в том случае, если

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

цесса ничуть не изменится, если такое же значение ему предоставит другой ре-

сурс.

Типичным примером привязки по

зпачепию {binding

by value) являются об-

ращения программ к стандартным библиотекам, как при программировании на

языке С или Java. Эти библиотеки всегда доступны на локальной машине, но их

3.4. Перенос кода 195

истинное местоположение

локальной файловой системе может быть различ-

ным.

Для

правильного выполнения процесса важны

не

конкретные имена фай-

лов,

а их

содержимое.

И, наконец, наиболее слабая форма связи имеет место

в том

случае, когда

процесс указывает

на

необходимость использования ресурса определенного

ти-

па. Подобная привязка по типу

{binding

by type) может быть проиллюстрирована

ссылками

на

локальные устройства, такие как принтеры, мониторы

и т. п.

При переносе кода мы часто нуждаемся

изменении ссылок

на

ресурсы,

при

этом изменять тип привязки ресурса

процессу запрещено. Можно ли изменять

ресурсы,

если да,

то

как, зависит от того, могут ли они быть перенесены

на

ма-

шину-приемник вместе

кодом. Конкретнее, нам нужно определить связь ресур-

сов

машиной

рассмотреть варианты.

Неприсоедипенные

ресурсы {unattached

resources) могут быть

легкостью перенесены

машины

на

машину. Файлы

(данных)

этом случае обычно связаны только

переносимой программой.

противоположность им, перенос или копирование

связанных ресурсов

{fasten-

resources)

возможно лишь

относительно большими затратами. Типичными

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

или web-

сайты целиком. Несмотря

на то

что

эти

ресурсы теоретически

не

зависят

от те-

кущей машины, часто бывает невозможно перенести

их в

другую среду.

И, наконец,

фиксированные

ресурсы {fixed

resources)

изначально привязаны

к конкретной машине или среде

и не

могут быть перенесены

на

другую. Фикси-

рованными ресурсами часто бывают локальные устройства. Другой пример фик-

сированных ресурсов

локальные конечные точки взаимодействия.

Скомбинировав три типа привязки ресурсов

процессам

три типа привяз-

ки ресурсов

машине, получим девять комбинаций, которые следует рассмот-

реть,

обсуждая вопрос переноса кода.

Эти

девять комбинаций иллюстрирует

табл. 3.2. Используются следующие сокращения:

—

организовать глобальную ссылку;

"¥ MV

—

перенести ресурс;

СР

—

копировать значение ресурса;

-¥ RB

—

выполнить новую привязку процесса

локальному ресурсу.

Таблица 3.2. Варианты переноса кода на другую машину

Привязка ресурса

машине

Неприсоединен- Связанный Фиксированный

ный ресурс ресурс ресурс

Привязка

М\/(илиОР)

GR (или MV)

по идеи-

Привязка тификатору

ресурса Привязка СР(илиМ\/, GR) ОЯ(илиСР)

к процессу по значению

Привязка RB (или MV, СР) RB (или GR, СР) RB (или GR)

по типу

Рассмотрим сначала возможности, возникающие при привязке процесса

ре-

сурсу

по

идентификатору. Если ресурс неприсоединенный, лучше всего перене-

196 Глава 3. Процессы

сти его на другую машину вместе с кодом. Однако если этот ресурс используется

переносимым процессом совместно с другими, следует организовать на него гло-

бальную ссылку

—

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

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

или фиксированный, организация глобальной ссылки также является наилуч-

шим решением проблемы.

Важно, что реалргзация системы глобальных ссылок может быть сложнее про-

стого использования URL и иногда оказывается слишком дорогостоящей. Рас-

смотрим, например, программу обработки высококачественных изображений на

отдельной рабочей станции. Создание в реальном времени высококачественных

изображений

—

это задача, требующая интенсивных вычислений, поэтому про-

грамма может быть перенесена на высокопроизводительный вычислительный

сервер. Организация глобальных ссылок на рабочую станцию будет означать ор-

ганизацию связи между сервером и рабочей станцией. Кроме того, серьезная об-

работка, происходящая одновременно на сервере и рабочей станции, потребует

соблюденрш определенных требований к скорости передачи изображений. В ре-

зультате может оказаться, что перенос программы на вычислительный сервер не

оправдан просто потому, что цена поддержания глобальных ссылок чересчур вы-

сока.

Другим примером трудностей с поддержанием глобальных ссылок может

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

ствия. В этом случае мы имеем дело с фиксированными ресурсами, привязанны-

ми к процессу по идентификатору, поэтому имеется два основных решения. Од-

но из них состоит в том, чтобы позволить процессу после переноса установить

соединение с исходной машиноР!, создав там отдельный поток выполнения, кото-

рый просто будет перенаправлять все приходящие сообщения на новое «место

жительства» процесса. Основным недостатком такого подхода является то, что

при сбоях или повреждении исходной машины связь с перенесенным процессом

будет прервана. Другое решение состоит в том, чтобы, взяв все процессы, связан-

ные с перенесенным, поменять их глобальные ссылки и пересылать сообщения

на новую конечную точку взаимодействия целевой машины.

Другая ситуация возникает в случае привязке! по значению. Рассмотрим сна-

чала фиксированные ресурсы. Комбинация фиксированных ресурсов и привязки

по значению возможна, например, в случае использования процессом участка па-

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

случае может потребовать от нас реализации распределенной разделяемой памя-

ти,

о которой мы говорили в главе 1. Однако чаще всего подобное решение не-

приемлемо.

Связанные ресурсы, ссылка на которые производится по значению,

—

это ча-

ще всего библиотеки времени исполнения. Обычно допускается копирование

этих ресурсов на другую машину, причем это копирование может быть осущест-

влено до переноса кода. Организация глобальных ссылок может оказаться хоро-

шей альтернативой копированию в том случае, если нужно скопировать боль-

шой объем данных, например словари и тезаурусы текстового редактора.

3.4. Перенос кода 197

Наиболее простой случай

—

неприсоединенные ресурсы. Наилучшее решение

при этом

—

скопировать (или переместить) ресурсы в новое место, исключая ва-

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

нем случае единственным выходом будет создание глобальных ссылок.

Последний вариант

—

привязка по типу. Независимо от способа привязки ре-

сурса к машине решение состоит в новой привязке процесса к локальным ресур-

сам того же типа. Только в том случае, если ресурсы данного типа на локальной

машине отсутствуют, мы можем скопировать или переместить оригинальные ре-

сурсы на новое место или организовать глобальные ссылки на них.

3.4.3. Перенос кода

гетерогенных системах

Ранее мы предполагали, что перенесенный код может быть с легкостью выполнен

на целевой машине. Это предположение относилось исключительно к гомоген-

ным системам. Обычно, однако, распределенные системы создаются из набора ге-

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

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

чтобы поддерживались все эти платформы, то есть сегмент кода должен выпол-

няться на всех этих платформах без перекомпиляции текста программы. Кроме

того,

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

форм будет представлен правильно.

Проблемы могут быть частично устранены в том случае, если мы ограничим-

ся слабой мобильностью. В этом случае обычно не суш.ествует такой информа-

ции времени исполнения, которую надо было бы передавать от машины к машине.

Это означает, что достаточно скомпилировать исходный текст программы, соз-

дав различные варианты сегмента кода

—

по одному на каждую потенциальную

платформу.

В случае сильной мобильности основной проблемой, которую надо будет ре-

шить, является перенос сегмента исполнения. Проблема заключается в том, что

этот сегмент в значительной степени зависит от платформы, на которой выпол-

няется задача. На самом деле перенести сегмент исполнения, не внося в него ни-

каких изменений, можно только в том случае, если машина-приемник имеет ту

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

Сегмент исполнения содержит закрытые данные процесса, его текущий стек

и счетчик программы. Стек обычно содержит временные данные, такие как зна-

чения локальных переменных, но может также содержать и информацию, зави-

сящую от платформы, например значения регистров. Важно отметить, что если

бы нам удалось избавиться от данных, зависящих от платформы, то перенести

сегмент на другую машину и продолжить исполнение там было бы значительно

проще.

Решение, работающее в случае процедурных языков, таких как С или Java,

показано на рис. 3.10. Перенос кода ограничен несколькими конкретными мо-

ментами выполнения программы. Точнее, перенос возможен только в момент

вызова очередной подпрограммы. Под подпрограммой имеется в виду функция

С,

метод в Java и т. п. Исполняющая система создает собственную копию про-

198 Глава 3. Процессы

граммного стека, причем машинно-независимую. Мы будем называть эту копию

стеком переноса

{migration

stack). Стек переноса обновляется при вызове под-

программы или возвращении управления из подпрограммы.

При вызове подпрограммы исполняющая система выполняет маршалинг дан-

ных, которые были помещены в стек во время предыдущего вызова. Эти данные

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

метров текущего вызова процедуры. Данные после маршалинга помещаются

в стек переноса вместе с идентификатором вызванной подпрограммы. Кроме того,

в стек переноса помещается адрес (в форме метки перехода), с которого должно

продолжаться исполнение после возвращения из подпрограммы.

Локальные

операции

стека В

Помещение параметров

вызова после их маршалинга

в стек переноса

Вызов _

из

А"

Программный

стек

Локальные

переменные

процедуры В

Метка возврата

(перехода)

в процедуру А

из процедуры В

Значения

параметров

процедуры В

Идентификация

процедуры В

Локальные

переменные

процедуры А

Метка возврата

в процедуру,

вызвавшую

процедуру А

Значения

параметров

процедуры А

Идентификация

процедуры А

Стек переноса

(данные только

после маршалинга)

Рис. 3.10. Принцип работы стека переноса, поддерживающего перенос

сегмента исполнения в гетерогенных средах

Если перенос кода происходит в точке вызова подпрограммы, исполняющая

система производит сначала маршалинг всех глобальных данных программы, со-

ставляющих сегмент исполнения. Данные, специфичные для данной машины,

и текущий стек игнорируются. Данные после маршалинга и стек переноса пере-

даются на ожидающую их машину. Кроме того, на машину-приемник загружает-

3.4. Перенос кода 199

ся соответствующий сегмент кода, содержащий подходящие для ее архитектуры

и операционной системы код. На машине-приемнике выполняется демаршалинг

полученных данных сегмента исполнения, и из стека переноса формируется но-

вый стек исполнения. После этого исполнение может быть продолжено простым

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

Ясно,

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

генерирует код для обновления стека переноса при каждом входе в подпрограм-

му или выходе из нее. Компилятор должен также генерировать в вызывающем

коде метки, позволяющие реализовать выход из подпрограммы в виде переходов

(машинно-независимых). Кроме того, мы нуждаемся в подходящей исполняю-

щей системе. Тем не менее существует множество систем, успешно использую-

щих подобную технологию. Так, в [127] показано, как можно обеспечить перенос

программ, написанных на C/C++, в гетерогенных системах путем небольших из-

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

ключительно директивы препроцессора.

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

сходны с проблемами переносимости. Не будет неожиданностью то, что также

сходны и методы их решения. Так, например, в конце 70-х годов было предложе-

но простое решение, позволившее решить множество проблем с переносом языка

Pascal на различные машины. Таким решением стала генерация промежуточного

машинно-независимого кода для абстрактной виртуальной машины [40]. Эта ма-

шина, разумеется, требовала реализации на множестве различных платформ,

благодаря которой программы на языке Pascal могли работать на них всех. Не-

смотря на то что эта простая идея некоторое время находила широкое примене-

ние,

она никогда не считалась общим решением всех проблем переносимости

для других языков, особенно С.

По прошествии приблизительно 20 лет проблему переноса кода в гетероген-

ных системах начали решать средствами языков сценариев, а также языков, об-

ладающих высокой степенью переносимости, таких как Java. Все эти решения,

в общем, основаны на виртуальной машине, которая интерпретирует либо непо-

средственно исходные тексты программ (в случае языков сценариев), либо про-

межуточный код, выдаваемый компилятором (для

Java).

Предложить свой товар

в нужном месте в правильное время оказывается важно и для разработчиков

языков программирования.

Единственный серьезный недостаток переносимости, реализуемой при помо-

щи виртуальных машин, состоит в том, что приходится ограничиваться конкрет-

ным языком, да еще таким, которого частенько никто не знает. По этой причине

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

вующими языками.

3.4.4. Пример

—

D'Agent

Чтобы проиллюстрировать перенос кода, рассмотрим теперь платформу проме-

жуточного уровня, поддерживающую различные формы переноса кода. D'Agent,

или полностью Agent TCL, — это система, построенная на основе концепции

200 Глава 3. Процессы

агента. Агентом в системе D'Agent называется программа, которая в гетерогенной

системе способна перемещаться с одной машины на другую. Сейчас мы сосредо-

точимся на возможностях переноса кода в системе D'Agent, а к более общему об-

суждению программных агентов вернемся в следующем пункте. Мы также проиг-

норируем вопросы безопасности, о них мы поговорим в главе 8. Дополнительную

информацию по D'Agent можно найти в [180, 242].

Обзор переноса кода в

D'Agent

Агент в системе D'Agent

—

это программа, которая может перемещаться с одной

машины на другую. В принципе программы могут быть написаны на разных язы-

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

На практике это означает, что программы в D'Agent пишутся на интерпретируе-

мых языках, а конкретнее, на командном языке утилит (Tool Command Language,

Tel),

Java или Scheme [336, 375]. Использование исключительно интерпретируе-

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

Программа, или агент, исполняется в процессе, запущенном интерпретатором

языка, на котором эта программа написана. Мобильность поддерживается тремя

способами

—

посредством инициированной отправителем слабой мобильности,

посредством сильной мобильности с переносом процессов и, наконец, посредст-

вом сильной мобильности с клонированием процессов.

Слабая мобильность реализуется при помощи команды agent_subm1t. В каче-

стве параметра используется идентификатор машины, на которую переносится

код. На этой же машине выполняется сценарий. Сценарий

—

это не что иное, как

последовательность инструкций. Сценарий переносится на машину-получатель

вместе со всеми описаниями процедур и копиями переменных, которые необхо-

димы для его выполнения на этой машине. На машине-получателе процесс за-

пускает подходящий интерпретатор, который и выполняет сценарий. В понятиях

вариантов переноса кода (см. рис. 3.9), D'Agent обеспечивает инициированную

отправителем слабую мобильность, когда перенесенный код выполняется в от-

дельном процессе.

В качестве примера слабой мобильности в D'Agent рассмотрим листинг 3.4.

В нем представлена часть простого агента на языке

Тс1,

которая посылает сцена-

рий на удаленную машину. В этом агенте процедура factorial получает единст-

венный параметр и рекурсивно вычисляет факториал для значения параметра.

Переменные numbers и machine должны быть правильно инициализированы (пу-

тем запроса значения у пользователя), после чего агент вызывает команду agent_

submit. На целевую машину, определяемую значением переменной machine, вслед

за определением процедуры factorial и исходным значением переменной number

пересылается следующий сценарий:

factorial $number

D'Agent автоматически вычисляет результат и возвращает его отправителю.

Вызов agent_receive приводит к блокированию агента, инициировавшего пере-

нос,

до момента возвращения ему результата.