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

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

12.3.

Jini

771

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

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

на объекты.

JavaSpace можно прочитать только экземпляры тех кортежей, ко-

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

держат либо ссылки на реальные объекты, либо значение

NULL.

А I Запись

"Т А

Вставка

копии А

Вставка

копии В

Экземпляр

кортежа

>И ^

[с

Возвращение

(и,

возможно,

удаление)

кортежа С

JavaSpace

Рис.

12.11.

Обобщенная организация пространства JavaSpace в Jini

Чтобы сопоставить экземпляр кортежа

JavaSpace эталонному кортежу, обыч-

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

полей со значением

NULL.

Для каждого экземпляра кортежа того же типа, что и

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

полями эталонного кортежа. Два поля совпадают, если оба они содержат копии

одной и той же ссылки или если поле в эталонном кортеже равно

NULL.

Экземп-

ляр кортежа совпадает с эталонным кортежем, если попарно совпадают соответ-

ствующие поля.

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

жем (который является частью операции read), выполняется демаршалинг этого

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

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

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

JavaSpace.

Обе операции блокируют вызвавший их

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

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

возвращающие управление, если нужного кортежа не существует.

По сравнению с моделью публикации/подписки, используемой в TIB/Rendez-

VOUS,

процессы, применяющие JavaSpace, не должны выполняться одновременно.

На самом деле, если пространство JavaSpace реализовано как сохранное храни-

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

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

стояща. По этой причине разработка высокоэффективных реализаций JavaSpace

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

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

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

ком проблем масштабируемости является генеративная связь. Ниже мы еще вер-

немся к этому вопросу.

Архитектура

JavaSpace образует лишь одну из частей системы

Jini.

Как и TIB/Rendezvous, Jini

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

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

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

процессов и служб. Все взаимодействие в существующих системах Jini построено

на обращениях RMI языка Java.

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

это показано на рис. 12.12. Самый нижний уровень образует инфраструктура. На

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

поддерживают взаимодействие посредством обращений RMI языка Java. Следу-

ет отдельно отметить одно важное свойство модели Jini: клиенты легко могут

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

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

Jini,

в том числе и вир-

туальная машина

Java,

выполняться не может. Поэтому регистрирующие и поис-

ковые службы также относятся к инфраструктуре Jini.

Пользовательские службы Jini

Внешние средства

Инфраструктура Jini

Рис. 12.12. Многоуровневая архитектура системы Jini

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

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

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

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

фейсов транзакций.

Самый верхний уровень состоит из клиентов и служб. В противоположность

остальным двум уровням Jini не определяет состав этого уровня однозначным

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

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

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

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

Далее мы подробнее рассмотрим систему

Jini,

разбирая каждый из семи базо-

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

части книги. При этом мы сосредоточим свое внимание на особенностях приме-

нения этих принципов в Jini, системе согласования, в которой ключевую роль

играют пространства JavaSpace.

Менеджер

транзакций

Интерфейсы

транзакций

Сервер

JavaSpace

События

и уведомления

Служба

поиска

• •

•

• • •

Java RMI

Сервер Т

защиты ±

Интерфейсы

аренды 1

Другие средства Т

ядра

12.3.

Jini

773

12.3.2.

Связь

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

Jini являются обра-

щения RMI языка Java. Мы обсуждали RMI в главе 2 и повторяться не будем.

Кроме генеративной связи, присущей модели JavaSpace (мы говорили об этом

чуть выше), в число механизмов взаимодействия Jini входит простая подсистема

событий и уведомлений, которую мы сейчас рассмотрим.

События

Модель событий Jini относительно проста. Если в рамках объекта происходит со-

бытие, которое может быть интересно клиенту, клиенту разрешается зарегистри-

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

то есть когда событие произойдет, объект уведомит об этом зарегистрированного

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

слал уведомление о наступлении события в другой процесс. В этом случае объекту

пересылается удаленная ссылка на

объект-слушатель {listener

object),

обратный

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

RMI языка Java).

Регистрация всегда арендуется. Когда срок аренды истекает, зарегистриро-

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

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

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

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

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

объекта-слушателя, зарегистрированного для этого события. При следующем

наступлении события объект-слушатель вызывается снова. Поскольку система

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

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

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

бытий.

Запись

Вставка

копии С

Запрос об

уведомлении Т

о вставке С

У^®А0мле;^'^7 4. Поиск кортежа^

типа Т

5. Возвращение

(и,

возможно,

удаление)

кортежа С

Рис. 12.13. Использование событий в JavaSpace

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

События также могут использоваться и

JavaSpace. Так, в частности, клиент

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

экземпляр кортежа. Для этого клиент вызывает операцию notify, реализованную

во всех пространствах JavaSpace. Эта операция получает в качестве исходных

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

щимися в JavaSpace, точно так же, как это происходит в ходе операций read или

take.

Использование событий

JavaSpace иллюстрирует рис.

12.13.

Отметим, что

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

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

и удалить его из JavaSpace. Подобные условия гонок

—

не редкость для генера-

тивной связи и избежать их обычно нелегко.

12.3.3.

Процессы

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

ра JavaSpace часто требует особого внимания. Давайте кратко рассмотрим неко-

торые вопросы, связанные с реализацией сервера

JavaSpace.

Мы сконцентрируем

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

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

нескольким машинам. Последний обзор методов реализации исполняющих сис-

тем с кортежами имеется в

[388].

Эффективная распределенная реализация JavaSpace должна решать две про-

блемы:

4 Как эмулировать ассоциативную адресацию без глобального поиска.

4 Как распределить экземпляры кортежей по машинам и как их потом обна-

ружить.

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

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

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

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

мер,

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

ределить, в каком подпространстве производится данная операция write, read

или take. Такое дробление означает, что поиск экземпляра кортежа будет произ-

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

Кроме того, каждое из этих подпространств можно организовать в виде хэш-

таблицы, использующей i-e поле или его часть в качестве ключа хэш-таблицы.

Напомним, что каждое поле экземпляра кортежа ~ это подвергнутая маршалин-

гу ссылка на объект. Jini не определяет способ маршалинга, поэтому маршалинг

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

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

она указывает. Таким образом, вызов операций write, read или take может осуще-

ствляться путем вычисления значения хэш-функции i-ro поля, в результате чего

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

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

12.3.

Jini

775

если z-e поле при операции read или take равно

NULL,

хэширование невозможно,

и придется, по всей вероятности, провести полный поиск в подпространстве. Од-

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

можно избежать.

Используется также и дополнительная оптимизация. Например, схема хэши-

рования, описанная выше, распределяет кортежи в заданных подпространствах

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

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

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

функцией хэширования является модуль числа машин, число контейнеров будет

расти в линейной зависимости от размера системы [63].

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

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

тежей можно реализовать в виде хэш-таблиц в глобальной памяти, по одной на

каждое подпространство. При осуществлении операции JavaSpace соответствую-

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

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

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

темы. Если в нашем распоряжении имеется надежная широковещательная рас-

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

странств на всех машинах, как показано на рис. 12.14. При осуществлении

записи (write) новый экземпляр кортежа рассылается по всем машинам и добав-

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

Широковещательная рассылка процессом

рассылка кортежа операции write

\щ

\ 1

кЧ

1 А

/•

! : ! ! TN

Сеть

Локальное выполнение

процессом операции take

V-

Удаление

кортежа Подпространства

шт

Сеть

Рис. 12.14. Пространство JavaSpace можно распределить между машинами

(дробление JavaSpace на подпространства показано пунктирными линиями).

Рассылка кортежей при выполнении операции write (а). Операции read

локальны,

но удаление экземпляров при выполнении операции take

также должно распространяться на все машины (б)

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

ляется на каждой из них в соответствуюш.ее подпространство. Поиск при выпол-

нении операции read или take производится в локальном подпространстве. Од-

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

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

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

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

подтверждения.

Эта структура проста, но при ее масштабировании (если система будет нара-

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

мы.

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

умно дорого.

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

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

как показано на рис. 12.15. Для выполнения операции read или take требуется

широковещательная рассылка эталонного кортежа. Каждая машина, получившая

его,

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

ветствующий отклик.

Локальное выполнение

процессом операции write

: : 1 :

Ш^

Сеть

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

процессом эталонного кортежа Широковещательная рассылка эталона

vJ_i_J_

Ш^

1 ч

/" ;

; ; I ! Г\

! : : :

J \

UjNiiJ

Сеть

Рис, 12.15. Не реплицированное пространство JavaSpace. Операция write

•выполнятся локально (а). Операции read и take требуют

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

экземпляра кортежа (б)

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

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

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

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

удовлетворен. Если запрос приводит к передаче двух или более экземпляров кор-

12.3.

Jini 777

тежа, соответствующих эталону, они трактуются как локальные операции write.

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

лись,

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

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

загрузки. В [84] подобная методика описана для реализации пространства корте-

жей Linda в локальной сети.

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

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

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

Когда процесс с машины Л хочет выполнить операцию write, он производит

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

ниями всем маширшм в своей строке решетки. Когда процесс с машины В хочет

выполнить операцию read или take для экземпляра кортежа, он производит ши-

роковещательную рассылку эталонного кортежа на все машины в своем столбце.

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

мере

—

С), имеющая и экземпляр кортежа, и эталонный кортеж, и эта машина

обнаружит соответствие и пошлет экземпляр кортежа запросившему его процес-

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

ждали в главе 6. Он был использован при реализации системы Linda [7] и про-

странства кортежей в кластере

[461].

п п п п п

In и п п п

п п п п п

D П П П П

п п п п п

'П

1 1

[Ц

[в]

п п

D П

п п

А рассылает

на эти машины

В рассылает эталон

на эти машины

Рис. 12.16. Частичная рассылка обычных и эталонных кортежей

Реализации, которые мы обсуждали, имеют серьезные проблемы масштаби-

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

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

бальных реализаций пространства кортежей не существует. В лучшем случае

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

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

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

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

Space [107] и WCL

[389].

В WCL, например, каждый сервер пространства корте-

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

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

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

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

остается открытым.

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

в Jini отсутствует служба именования в традиционном понимании этого терми-

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

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

вать в архитектуре Jini в виде приложения верхнего уровня, но в ядро Jini она не

входит. Тем не менее в состав Jini входит служба, которая позволяет клиентам на-

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

по атрибутам. Далее мы рассмотрим эту поисковую службу.

Служба поиска Jini

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

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

ключения. В принципе JavaSpace в состоянии реализовать такую службу. Всякий

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

JavaSpace

описывающий ее экземпляр кортежа. Клиенты, которые ищут определенную служ-

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

бы,

соответствующей заявленным требованиям.

Не полагаясь

на

JavaSpace,

Jini имеет собственную специализированную

служ-

бу

поиска (lookup

service),

являющуюся частью инфраструктуры нижнего уровня

(см.

рис. 12.12). Все службы верхнего уровня должны зарегистрироваться в ней,

отослав службе поиска набор пар

{атрибуту

значение), которые описывают, на-

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

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

кортежем

JavaSpace.

Служба поиска возвращает информацию о подходящих под

эталон службах. Давайте кратко рассмотрим, как работает эта служба поиска.

Каждая служба имеет связанный с ней

идентификатор службы {service

iden-

tifier),

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

генерируемое службой поиска. Служба использует этот идентификатор для ре-

гистрации

элемента службы {service item)

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

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

Поле ServicelD содержит идентификатор службы, присвоенный этой службе

службой поиска. Идентификатор используется как уникальный ключ для служ-

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

иска выдала бы одинаковые идентификаторы.

Таблица 12.4. Структура элемента службы

Поле Описание

12.3.

Jini 779

ServicelD Идентификатор службы, ассоциированный с этим элементом

Service Ссылка на объект (возможно, удаленный),

реализующий службу

AttributeSets Набор кортежей, описывающих службу

Поле Service содержит ссылку на объект. Во многих случаях это ссылка на

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

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

ния RMI языка

Java.

Напомним, что в главе 2 мы говорили, что удаленная ссыл-

ка на объекты Java часто реализуется путем маршалинга заместителя. Остается

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

екту.

Поле AttributeSets представляет собой набор кортежей, схожих с кортежами

JavaSpace. Каждый кортеж, в сущности, соответствует объекту

Java,

а каждое по-

ле кортежа описывает пару (атрибут, значение) этого объекта. Используя те же

методы, что и в JavaSpace, клиент может выполнять поиск определенного экземп-

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

кортежи, которые соответствуют эталону.

Как и в случае

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

домлять его о случаях добавления элементов службы, соответствующих эталон-

ному кортежу клиента.

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

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

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

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

гибкость.

Таблица 12.5. Примеры встроенных кортежей для элементов служб

Тип кортежа Атрибуты

Servicelnfo Имя, производитель, продавец, версия, модель,

серийный номер

Location Этаж, комната, здание

Address Улица, организация, организационная единица, местность, штат

или район, почтовый код, страна

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

Однако Jini допускает одновременное наличие нескольких таких служб. Каждая

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

поиска может быть распределена по нескольким машинам.

В нашем описании мы пропустили один важный вопрос, а именно, как найти

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

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

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

стный адрес.

Jini используется другой подход. Клиенту предлагается для лока-

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

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

только для локальных сетей.

Кроме того, служба поиска и сама регулярно объявляет о своем местоположе-

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

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

воспользоваться этими сведениями. Детали соответствующих протоколов мож-

но найти в

[483],

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

поиска.

Аренда

с вопросами именования связаны вопросы управления ссылками на объекты. Как

мы говорили в главе

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

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

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

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

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

действительными и удаляются из списка ссылок. Когда список на объект стано-

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

В системе Jini аренда активно используется для удаления объектов, на кото-

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

Java-

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

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

объекту, который ее осуществляет, указать желаемое время аренды.

Аренда никогда не дает полной гарантии. Когда процесс устанавливает арен-

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

ного объекта в течение как минимум определенного времени. Процесс, которому

предоставлена аренда, всегда может попросить о ее продлении. Однако арендо-

датель вправе решать, согласиться на продление аренды или нет.

Интерфейсы аренды стандартизованы. При использовании аренды

Jini всю-

ду соблюдаются одни и те же спецификации. Детальное описание интерфейсов

можно найти в

[483].

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

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

сов подобных механизмов, а именно блокирующие операции read и take, реализо-

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

личных шаблонов синхронизации. Примеры подобных шаблонов в отношении

параллельных программ можно найти в [85]. Помимо синхронизации посредст-

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

мы сейчас и поговорим.