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

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

12.2.

TIB/Rendezvous 761

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

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

ДР1С-

петчеризации.

Создание слушателя событий

У Период подписки

Уничтожен наблюдатель событий

Постановка объекта

события в очередь

Обратный вызов •

Завершение обратного вызова

Обработка обратного / ;

^ вызова ^ Обрат)ный вызов

Постановка объекта

события в очередь

Постановка объекта

события в очередь

\т

Обработка обратного

вызова

Завершение обработки

события

Время

Приход сообщения

Рис. 12.5. Обработка входящих сообщений в TIB/Rendezvous.

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

редей

{queue

group).

Каждой очереди в группе можно назначить приоритет. Дис-

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

падающие в очередь с максимальным приоритетом. Если эта очередь пуста, он

займется объектами событий из следующей по приоритету очереди. На

рис.

12.6, а

показана группа из четырех очередей событий. Для того же набора объектов со-

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

редь событий.

Группа очередей

Очередь

событий

Снижение уровня приоритета

Темы

АиВ

1®

САЮ

Тема С

Темы

ОиЕ

Прочие

темы

(АТ)

СЮ

(А2)

[сТ]

(С2]

СЮ

Рис. 12.6. Приоритезация событий в группе очередей событий (а). Очередь событий,

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

762 Глава 12. Распределенные системы согласования

Если ни одного объекта событий нет, диспетчер блокируется. При обращении

к функции обратного вызова для выбранного объекта события диспетчер остает-

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

и в

том случае, ес-

ли в группу очередей добавляется объект события с приоритетом более высоким,

чем

обрабатываемого объекта.

12.2.3.

Процессы

Базовая организация системы TIB/Rendezvous довольно проста. На каждом хосте

обычно работает один демон контактов, который, как было сказано выше, отвеча-

ет за все локальное сетевое взаимодействие. При необходимости демон контактов

заменяется маршрутизирующим демоном, который отвечает

за

весь глобальный

трафик. Маршрутизирующий демон имеет расширенную,

по

сравнению

демо-

ном контактов, функциональность.

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

на

его хосте

виде отдельного про-

цесса.

Все

взаимодействие осуществляется

при

помоищ библиотеки функций,

которая скомпонована

приложенршм клиента и,

свою очередь, пересылает со-

общения локальному демону. Детальное описание этой библиотеки

подробно-

сти интерфейса программ

на

языке

можно найти

[459].

12.2.4. Именование

До

сих

пор

этой книге

мы

считали имена средством обращения

сущностям,

которые созданы

управляются распределенной системой. Типичными примерами

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

т.

п.

Основная особенность системы публикации/подписки, такой

как

TIB/Ren-

dezvous, состоит

адресации имен тем. Именование

целью адресации

этом

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

вают

на

сущности,

как на

особые образования, находящиеся где-то

системе

и требующие обработки.

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

процессов-отправителей (издателей)

группой процессов-получателей (подпис-

чиков).

В TIB/Rendezvous имя темы

—

это последовательность строковых меток, раз-

деленных точками, похожее

на

DNS-имя. Имя темы должно всегда начинаться

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

Имя

темы ограничено

255 символами,

значит, метка может иметь длину

до 252

символов. Примеры

правильных

неправильных имен тем представлены

табл.

12.2.

Таблица 12.2. Примеры правильных и неправильных имен тем

Пример Правильность

Books.ComputerSystems.DisthbutedSystems

Да

.ftp.cs.vu.nl Нет, поскольку начинается

точки

ftp.cs.vu.nl

Да

NEWS.res.comp.os

Да

Пример

Maarten..vanSteen

Maarten.R.vanSteen

12.2.

TIB/Rendezvous 763

Правильность

Нет, поскольку имеется пустая метка

Да

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

ки,

могут использоваться символы-заменители. Имеется два символа-замените-

ля.

Звездочка (*), указанная вместо метки, обозначает, что на этом месте может

находиться любая метка. Символ «больше» (>) означает, что в оставшейся части

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

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

волов-заменителей представлены в табл. 12.3.

Таблица 12.3. Примеры символов-заменителей в именах тем

Имя с символом-заменителем Реальное имя темы

*.CS.

VU.

п1

ftp.cs.vu.nl; www.cs.vu.nl

п1.

VU.

nl.vu.cs.ftp; nl.vu.cs.zephyr; nl.vu.few.www

NEWS.

comp.

*. books NEWS.сотр.os.books; NEWS.сотр.ai.books;

NEWS.comp.se.books; NEWS.comp.theory.books

Маршрутизирующие демоны можно сконфигурировать так, чтобы они фильт-

ровали входящие и исходящие сообщения в соответствии с символами-замени-

телями. С точки зрения входящих сообщений это выглядит так, словно маршру-

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

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

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

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

ве имени темы указана строка

NEWS.>),

то и клиент будет получать только новост-

ные сообщения.

Таким же образом могут быть ограничены и исходящие сообщения. В резуль-

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

Каждое сообщение, удовлетворяющее условиям подписки, передается маршру-

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

Подобная двусторонняя фильтрация входящих и исходящих сообщений мо-

жет существенно снизить трафик в глобальных сетях. По своей природе двусто-

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

ла рассылки новостей NNTP [36, 223]. Отметим, что в подобной схеме групповой

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

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

пользовать содержимое письма, как описано в [35].

12.2.5.

Синхронизация

Ядро TIB/Rendezvous предоставляет минимальную поддержку синхронизации про-

цессов. Единственное, что хоть как-то гарантируется,

—

доставка сообщений от

764 Глава 12. Распределенные системы согласования

одного источника в порядке FIFO, то есть тот факт, что сообщения с одним и тем

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

Вдобавок к ядру TIB/Rendezvous имеет выделенную службу транзакций, ко-

торая поддерживает трапзакционный обмен сообщениями {transactional messa-

ging).

Для транзакционного обмена сообщениями посылаемые и получаемые со-

общения можно рассматривать как части транзакции. Трапзакционный обмен

сообщениями реализуется в виде отдельного уровня поверх ядра системы TIB/Ren-

dezvous, как показано на рис. 12.7. Транзакции всегда производятся с операция-

ми,

относящимися к одному процессу. Объединение в одной транзакции опера-

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

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

в главе 7.

Машина клиента

Библиотека Библиотека

транзакций контактов

Машина клиента \ Менеджер транзакций

Приложение

ТХ

Приложение

ТХ

Демон

контактов

Приложение

ТХ

Демон

контактов

Демон

транзакций

Демон

контактов

Сеть

Рис. 12.7. Организация транзакционного обмена сообщениями

в отдельном уровне TIB/Rendezvous

Важную роль в транзакциях играет демон транзакций {transaction daemon),

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

мента их доставки всем подпргсчикам. Может существовать несколько демонов

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

ются только те сообщения, которые являются частью транзакции. Далее мы по-

ясним эту модель.

Процесс Р, как показано на рис. 12.8, может объединить несколько операций

издания и подписки в одной транзакции. Транзакция начинается посылкой не-

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

сеанс с процессом Р для отправки и приема сообщений в качестве части транзак-

ции. После этого, когда Р публикует сообщение по теме S, оно пересылается де-

мону, отвечающему за тему S, где и хранится до тех пор, пока Р либо подтвердит,

либо прервет транзакцию. Отметим, что до подтверждения транзакции опубли-

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

Сообщения

подтвержденной

транзакции, на которые подписан процесс

Р,

пе-

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

12.2.

TIB/Rendezvous 765

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

Когда Р получает сообщение, on уведомляет об этом демона транзакций, кото-

рый его хранит. Это уведомление гарантирует, что Р снова не получит то же са-

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

Отправка

на тему А

Менеджер

транзакционного

обмена

сообщениями

на тему А

гг

Процесс Р

-±1

Подписка на тему С

BEGIN_TRANSACTION

- Публикация на тему А

Сообщение о получении ^

—

Публикация на тему В

END TRANSACTION —

Отправка

Уна тему В

3. Подтверждение

Менеджер

транзакционного

обмена

сообщениями

на тему В

тт

Менеджер

|транзакционного|

обмена

сообщениями

на тему С

Публикация

на тему С

Сеть

Публикация

на тему А

Публикация

на тему В

Рис. 12.8. Транзакции в TIB/Rendezvous

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

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

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

Сообщение из подтвержденной транзакции передается подписчикам. Если по7^-

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

щениями или нет), сообщение отбрасывается. Сообщение сохраняется демоном

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

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

ждена транзакция, соответствующая этому сообщению.

Если в транзакцию вовлекается несколько демонов транзакций, TIB/Rendez-

vous использует для принятия решения о подтверлсдении или прерыванри! тран-

закции протокол двухфазного подтверждения.

Транзакциоиный обмен сообщениями может сочетаться с операциями с база-

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

закций). Такая гибкость может усложнить понимание семантики транзакций в

TIB/Rendezvous. Мы не будем вдаваться в детали, их можно найти в

[458].

12.2.6.

Кэширование и репликация

Никаких специальных средств кэширования или репликации в системе TIB/

Rendezvous не предусмотрено. Решение этР1х вопросов полностью возложено на

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

766 Глава 12. Распределенные системы согласования

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

TIB/Rendezvous не в состоянии обнаружить, что все эти сообщения

—

копии од-

ного и того же сообщения и все они доставляются подписчикам.

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

рый подобно серверу будет кэшировать последние п сообщений по определенной

теме. Когда процесс начнет работу в системе, он может попросить кэширующий

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

стрее понять, о чем идет речь.

12.2.7.

Отказоустойчивость

в TIB/Rendezvous предполагаются два способа поддержания отказоустойчиво-

сти.

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

тируют, что публикуемое сообщенрш не будет потеряно из-за отказов связи. Во-

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

Далее мы рассмотрим эти механизмы более подробно.

Надежная связь

в TIB/Rendezvous предполагается, что коммуникационные механизмы базовой

сети ненадежны. Чтобы компенсировать эту ненадежность, демон контактов, от-

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

нимум 60 с. При отправке сообщения демон добавляет к нему последовательнырт

номер (от темы этот номер не зависит). Принимающий сообщение демон может,

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

пропало (напомним, что сообщения посылаются всем демонам). Если обнару-

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

просьба повторить пересылку этого сообщения.

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

мер,

если принимающий демон запрашивает повторную отправку сообщения,

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

стоянии восстановить это сообщение. В нормальных условиях издатель и под-

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

возлагается на приложения.

Значительно больше в вопросе обеспечения надежной связи TIB/Rendezvous

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

пор TIB/Rendezvous предоставляет надежную групповую рассылку на базе груп-

повой рассылки (ненадежной) по IP-адресам. Для этого в TIB/Rendezvous ис-

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

прагматическая общая групповая рассылка {Pragmatic General Multicast, PGM),

описанный в

[427].

Мы кратко рассмотрим его.

PGM не дает абсолютной гарантии того, что в процессе групповой рассылки

сообщение рано или поздно дойдет до каждого получателя. На рис. 12.9, а пока-

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

телей не доходит. Идея PGM состоит в том, что получатель сам обнаруживает

потерю сообщений. Если таковые обнаружатся, отправителю посылается запрос

12.2.

TIB/Rendezvous 767

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

повой рассылки, в корне которого находится отправитель, как это показано на

рис.

12.9, б. Когда запрос на повторную отправку достигает промежуточного уз-

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

В этом случае он и совершает повторную отправку. В противном случае узел

просто пересылает запрос следующему узлу на пути к отправителю. Если ни один

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

в конце концов, делает отправитель.

Отправитель

^ Дерево

групповой

рассылки

^ пересылается

Маршрутизатор ООП только

PGM ^^ один запрос

Получатели потеряли Отправка запроса Избирательная

сообщение доставка пропавшего

сообщения

а б в

Рис. 12.9. Принцип работы PGM. Сообщение посылается по дереву групповой рассылки (а).

Маршрутизатор пересылает только один запрос на каждое сообщение (б).

Сообщение заново отправляется только тем получателям,

которые этого требуют (в)

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

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

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

ресылают отправителю только один запрос. Это позволяет защитить отправителя

от «обвала» сообщений об ошибке. Мы уже говорили об этой проблеме в главе 7,

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

сылки.

Второе, что делает PGM,

—

запоминает путь, по которому проходит запрос от

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

конец, посылает запрошенное сообщение во второй раз, PGM заботится о том,

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

образом, получателям, уже получившим это сообщение, лишнее сообщение не

причинит неудобств.

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

колу PGM система TJB/Rendezvous может обеспечить дополнительные меры на-

дежности путем

доставки сертифицированных сообщений

{certified

message

deli-

very).

В этом случае процесс использует для отправки или получения сообщений

отдельный транспорт, имеющий встроенный журнал регистрации {ledger) ото-

сланных и принятых сертифицированных сообщений. Процесс, собирающийся

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

768 Глава 12. Распределенные системы согласования

этих сообщений. Регистрация позволяет транспорту обеспечить дополнительные

механизмы надежности, которых не имеют демоны контактов. Большая часть этих

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

Если журнал регистрации реализован в виде файла, становится возможным

обеспечивать надежную доставку сообщений даже при отказах процессов. Так,

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

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

отправителя. После восстановления получатель просто связывается с журналом

регистрации и требует повторной передачи потерянных сообщений.

Отказоустойчивые группы процессов

Чтобы иметь возможность маскировать отказы процессов, TIB/Rendezvous ис-

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

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

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

Коротко говоря, неактивный процесс

—

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

обрабатывать только некоторые события.

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

ответствующий ему уникальный ранг. Ранг процесса в группе определяется ве-

сом, назначенным ему вручную, причем два процесса в одной группе не могут

иметь одинаковый ранг. Каждой группе TIB/Rendezvous разрешено иметь не-

сколько (в зависимости от группы) активных процессов, которые называются

активной целью {active goal) группы. Во многих случаях активная цель ограни-

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

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

Активный процесс регулярно посылает сообщение прочим членам группы,

чтобы объявить, что он жив и работает. Если очередное сообщение от процесса

не пришло, промежуточный уровень TIB/Rendezvous автоматически активизР!-

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

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

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

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

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

Чтобы сохранить непротиворечивость активных процессов, необходимо осо-

бым образом «пробуждать» неактивные процессы перед их активизацией. Про-

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

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

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

Отметим, что эта схема близка к активной репликации, о которой мы говорили

в главе 6.

12.2.8.

Защита

Защита в TJB/Rendezvous сведена к организации защищенных каналов между

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

12.2.

TIB/Rendezvous 769

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

именно отсутствие ссылочной связ-

ности между отправителями

получателями. Как мы говорили ранее, появление

связности сводит всю модель

прямому согласованию. При выполнении взаим-

ной аутентификации,

как это

происходит

случае защищенных каналов, явная

связность отправителя

получателя неизбежна.

Организация защищенных каналов

TIB/Rendezvous начинается

публика-

ции зашифрованных данных. Публикуемые данные содержат удостоверение

от-

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

полу-

чателем. Если сообщение было отправлено нескольким подписчикам, каждый

из

них должен организовать

отправителем защищенный канал. Ключ, используе-

мый для расшифровки сообщения, одинаков для всех подписчиков.

Организация защищенного канала между, скажем, Алисой

Бобом основана

на обмене ключами по Диффи—Хеллману

сочетании

системой открытых клю-

чей (рис. 12.10). Мы предполагаем, что Алиса

Боб уже получили сертификаты,

содержащие открытые ключи друг друга.

Как

показано

на

рисунке, проверка

этих сертификатов является частью протокола организации защищенного кана-

ла. Кроме того,

мы

предполагаем,

что

Алиса

Боб, используя протокол обмена

ключами Диффи—Хелмана, создали общий секретный ключ

КА,В' МЫ

описывали

эту процедуру

главе

ЗГ

А.

КД,В(РА)

1 Кд.в^'^А'

f^B'

[4(RA.RB'^A.B)]^

) 1

•^А,в(^А2'^В'

[Че^Аг'^^В'КА.в)^)

Рис. 12.10. Организация защищенного канала в TIB/Rendezvous

Чтобы орга?шзовать защищенный канал, Алиса

Боб должны аутентифици-

ровать друг друга. Алиса начинает

посылки Бобу «одноразового» (попсе) слу-

чайного числа

RA,

зашифрованного общим ключом

КА,Ъ

(сообщение 1). Для ответа

Бобу нужно передать Алисе другое случайное число R^. Он это делает, вычисляя

значение хэш-функции H(RA,

RB, КА,В) И

подписывая

его

своим закрытым клю-

чом. Подписанное значение хэш-функции вместе

со

случайными числами

возвращается Алисе, причем все это шифруется ключом

КА,В

(сообщение 2).

Когда Алиса получает сообщение 2, она может определить, действительно

ли

оно прислано Бобом, вычислив значение хэш-функции

сверив его

со

значени-

ем,

которое подписал Боб.

Для

этой цели

ей

необходимо проверить сертификат

Боба,

котором содержится открытый ключ. Проверка сертификата сводится

к проверке того, действительно

ли

сертификат подписан сертифицирующей

ор-

ганизацией, которой Алиса доверяет.

Аутентр1фицировав Боба, Алиса должна дать ему возможность аутентифици-

ровать себя.

Для

этого

она

использует другое «одноразовое» случайное число,

RA2, И

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

она

получила

от

Боба

770 Глава 12. Распределенные системы согласования

(сообщение 3). Теперь и Боб может аутентифицировать Алису, и, таким образом,

организацию защищенного канала можно считать завершенной.

12.3.

Jini

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

система Jini компании Sun Microsystems. Отнесение Jini к системам согласования

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

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

на которой и будет сосредоточено наше внимание. Существует множество служб

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

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

Спецификация Jini, распространяемая Sun Microsystems, имеется в [443, 483].

Хорошее описание базовых механизмов Jini имеется в

[230].

12.3.1.

Обзор

Jini

—

это распределенная система, состоящая из разных, но взаимосвязанных

элементов. Она жестко привязана к языку программирования Java, хотя многие

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

Важной частью системы является модель согласования генеративной связи. Пре-

жде чем говорить об общей архитектуре системы Jini, давайте обсудим эту

модель.

Модель согласования

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

помощи Linda-подобной системы coтлsiCoв2inия JavaSpace [155,

442].

JavaSpace

—

это разделяемое пространство данных, в котором хранятся кортежи. Кортежи

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

Java.

В одной сис-

теме Jini могут сосуществовать несколько пространств JavaSpace.

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

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

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

ли кортеж содержит два разных поля, ссылающихся на один и тот же объект, то

кортеж, сохраняемый в реализации

JavaSpace,

будет содержать две подвергнутые

маршалингу копии этого объекта.

Кортеж помещается в пространство JavaSpace при помощи операции write,

которая сначала выполняет маршалинг кортежа, а затем сохраняет его. Каждый

раз при выполнении для кортежа операции write в JavaSpace сохраняется новая

подвергнутая маршалингу копия этого кортежа (рис. 12.11). Мы можем ссылать-

ся на каждую такую копию, как на экземпляр

кортежа

(tuple instance).

Интересный аспект генеративной связи в Jini

—

это способ чтения экземпля-

ров кортежа

JavaSpace.

Чтобы прочесть экземпляр кортежа, процесс предостав-

ляет другой кортеж и использует его как эталон (template), соответствующий