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

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

12.3.

Jini

781

Транзакции

Чтобы способствовать выполнению последовательностей операций над несколь-

кими объектами, Jini поддерживает транзакции, использующие протокол двух-

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

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

другим.

Однако Jini можно сконфигу-

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

Такой подход имеет важную особенность. Дело в том, что свойства ACID транз-

акции самой системой Jini не обеспечиваются. Взамен предполагается, что эти

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

акции. Однако взаимодействие между процессами соответствует шаблону транз-

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

Общую модель транзакций в Jini иллюстрирует рис. 12.17. Клиент А может

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

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

лить,

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

акции. Кроме того, менеджер может назначить только что созданной транзакции

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

ния транзакции.

BEGIN TRANSACTION

Менеджер

транзакций

JOIN

END_TRANSACTION

JOIN

Клиент

Участник Участник

Операции, являющиеся частью транзакции

Рис. 12.17. Общая организация транзакций в

Jini.

Толстые линии обозначают

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

протокола транзакций Jini

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

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

фейс,

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

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

транзакцрш, чтобы указать участнику транзакции, что ему делать. Задача участ-

ника

—

корректно реализовать эти методы.

Если транзакция заканчивается до истечения срока аренды, клиент указывает

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

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

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

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

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

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

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

в ходе существующей транзакции. И снова клиент контролирует организацию

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

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

транзакции.

Пространство JavaSpace также может участвовать в транзакциях. В транзак-

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

пересылает пространству JavaSpace сведения об операции, которую оно должно

выполнить, процесс может передать также и идентификатор транзакции. Если

пространство JavaSpace не было вовлечено в эту транзакцию, это нужно сделать.

Серверы JavaSpace, работая вместе с менеджером транзакций, гарантируют транз-

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

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

рый, собственно говоря, является частью

Jini,

поддерживают строгую двухфазную

блокировку. Мы говорили о двухфазной блокировке в главе 5.

12.3.6.

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

Как и в TIB/Rendezvous, в Jini не предусмотрено никаких специальных средств

кэширования или репликации. Эти аспекты полностью оставлены приложениям,

которые становятся частью системы

Jini.

Единственная служба, для которой Jini

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

сти,

—

это служба поиска.

12.3.7.

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

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

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

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

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

ния отказоустойчивости.

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

странств кортежей Linda (которые образуют основу пространств

JavaSpace).

Так,

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

кортежей. Кроме того, в [410] получила дальнейшее развитие программная мо-

дель с группировкой нескольких операций в транзакцию.

Что же касается связи, отметим, что фактически все взаимодействие осущест-

вляется посредством обращений RMI языка Java, а эти обращения обычно реа-

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

HTTP или TCP.

12.3.8.

Защита

Защита в Jini основана исключительно на возможностях защиты RMI языка Java.

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

RMI и в основном касающихся предохранения от динамически загружаемого ко-

12.4.

Сравнение TIB/Rendezvous и Jini 783

да путем самоанализа стека. Напомним, что важным свойством схемы самоанали-

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

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

В Jini введена специальная служба аутентификации и авторизации Java

{Java Authentication and

Authorization

Service^

JAAS), которая осуществляет ау-

тентификацию и авторизацию пользователей в системах на базе Java, таких как

Jini.

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

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

контроля доступа, от истийной реализации этих служб. Это разделение [394]

осуществляется при помощи

подключаемого

модуля аутентификации

(Pluggable

Authentication Module, РАМ). РАМ образует, в сущности, промежуточный уро-

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

предоставляет этим двум группам процессов стандартные интерфейсы. JAAS

—

это реализация РАМ на языке Java.

Приложение Приложение Приложение

Г t ^

Подключаемый модуль аутентификации

Служба

аутентификации

UNIX

Аутентификация

Kerberos

Рис. 12.18. Положение РАМ по отношению

к службам защиты

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

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

что

Java,

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

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

классами.

JAAS может так-

же работать и с пользователями.

Поскольку JAAS, в сущности, похожа на другие службы аутентификации

и авторизации, в том числе и те, которые мы уже рассматривали, мы не станем

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

JAAS можно почерпнуть

[247].

12.4. Сравнение TIB/Rendezvous и Jini

Две системы согласования, которые мы описали в этой главе, являются характер-

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

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

Философия

Как TJB/Rendezvous, так и Jini нацелены на организацию ссылочной несвязности

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

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

ными. TIB/Rendezvous ссылочную несвязность обеспечивает при помощи ме-

ханизма публикации/подписки, а Jini

—

генеративной связью через JavaSpace.

Кроме того, Jini обеспечивает еще и временную несвязность процессов.

Другое различие между этими системами состоит в том, что TIB/Rendezvous

обслуживает большую часть взаимодействия между процессами. В Jini же глав-

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

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

RMJ языка Java.

Связь

Как мы говорили, взаимодействие в TIB/Rendezvous осуществляется в первую

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

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

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

бальных сетях. Чтобы связь не зависела от приложений, сообщения сделаны са-

моопределяющимися.

В противоположность этой системе Jini, в сущности, использует групповую

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

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

реализуется обращениями RMI языка

Java,

в том числе и взаимодействие с серве-

рами JavaSpace. Другими словами, групповая рассылка применяется процессом

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

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

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

В обеих системах события играют важную, но различную роль. В TIB/Ren-

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

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

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

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

ны блокирующие операции.

События в Jini имеют другую природу. Каждый процесс может предложить

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

другой процесс для последующей передачи уведомлений. Когда происходит оп-

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

рый может быть соответствующим образом обработан. Механизм событий Jini

—

это,

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

процессов.

Процессы

Поскольку TIB/Rendezvous

Jini,

в сущности, содержат только средства взаимо-

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

12.4.

Сравнение TIB/Rendezvous и Jini 785

особенного. Кроме того, хотя обе системы поддерживают множество специфиче-

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

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

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

Именование

Если рассматривать вопросы именования, между TIB/Rendezvous

Jini имеется

три отличия. Имена в TIB/Rendezvous играют важную роль в контексте адреса-

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

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

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

По сравнению с TIB/Rendezvous имена

Jini имеют вид строк байтов, в кото-

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

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

в форме строки без значения (NULL).

Благодаря эффективности парадигмы публикации/подписки в TIB/Rendez-

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

решала бы имена в адреса процессов. В противоположность ей система Jini вы-

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

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

ется в виде последовательности строк байтов).

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

Системы TIB/Rendezvous и Jini поддерживают механизмы транзакций, но ис-

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

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

ции и получения сообщений (а возможно, и операций с базами данных) в единую

транзакцию. Транзакции (точнее, транзакционный обмен сообщениями) осуще-

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

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

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

удовлетворяли свойствам ACID.

Jini,

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

объединить в транзакцию несколько операций, вызванных клиентом. Однако

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

сти,

изолированности и долговечности транзакции,

—

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

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

совместно с серверами JavaSpace этот менеджер обеспечит соблюдение свойств

ACID для транзакций.

Работа транзакции в TIB/Rendezvous ограничена рамками одного процесса.

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

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

сообщениями. В Jini в одной транзакции могут участвовать несколько клиент-

ских процессов, хотя обычно инициативу по организации и завершению транз-

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

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

Вдобавок

транзакциям Jini поддерживает также механизм синхронизации

на основе блокирующих операций в JavaSpace, который эффективно реализует

распределенные блокировки. В TIB/Rendezvous нет никаких других механизмов

синхронизации, кроме транзакций.

Кэширование

репликация

Ни TIB/Rendezvous, ни Jini

не

поддерживают кэширование

репликацию. Эти-

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

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

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

TIB/Rendezvous поддерживает сохранную связь

—

как в форме сертифицирован-

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

так и в

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

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

щениями RMI языка Java.

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

процессов

на

промежуточном

уровне.

Jini не имеет специальных средств поддер-

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

будут реализовывать приложения.

Ни

одна

из

систем

не

имеет явных средств

восстановления после отказов, если не считать тех, которые реализованы как часть

транзакций.

Защита

и, наконец, TIB/Rendezvous поддерживает защиту

форме отдельного протоко-

ла организации защищенного канала между издателем

подписчиком. Для кон-

троля доступа

не

предпринимается ничего, этот вопрос остается приложениям,

использующим TIB/Rendezvous

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

ствия.

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

ты,

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

базе

Java.

Эти средства подразу-

мевают контроль доступа

на

уровне классов, который

мы

обсуждали

главе

а также аутентификацию

авторизацию пользователей

форме выделенного сер-

вера защиты JAAS.

Наиболее важные аспекты каждой

из

систем перечислены

табл.

12.6.

Таблица 12.6. Сравнение систем TJB/Rendezvous и Jini

Аспект TIB/Rendezvous Jini

Основная цель разработки Отсутствие связности Гибкая интеграция

процессов

Модель согласования Публикация/подписка Генеративная связь

Сетевое взаимодействие Групповая рассылка RMI языка Java

Сообщения Самоопределяющиеся Зависят

от

процесса

Механизм событий Входящие сообщения Служба обратного вызова

Процессы Общего назначения Общего назначения

12.5.

Итоги 787

Аспект TIB/Rendezvous Jini

Имена

Службы именования

Транзакции (операции)

Транзакции

(область видимости)

Блокировка

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

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

Группы процессов

Механизмы

восстановления

Защита

Символьные строки

Отсутствуют

Сообщения

Единственный процесс

Отсутствует

Отсутствуют

Имеется

Имеются

Явной поддержки нет

Защищенные каналы

Строки байтов

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

Обращения к методам

Несколько процессов

Как у операций

в JavaSpace

Отсутствуют

Имеется

Отсутствуют

Явной поддержки нет

Полностью определяется

механизмами защиты Java

12.5.

Итоги

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

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

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

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

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

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

менно.

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

—

это системы, основанные на

парадигме издателя/подписчика, такие как TIB/Rendezvous. В этой модели со-

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

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

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

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

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

впервые предложенную в системе Linda. Генеративная связь реализуется разде-

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

—

это типовая структура данных,

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

процесс отыскивает его при помощи эталонного кортежа. Кортеж, соответствую-

щий эталону, выбирается и возвращается запросившему его процессу. Если сов-

падений нет, процесс блокируется.

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

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

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

Связь может и далее осуществляться с сохранением анонимности. Основное

преимущество подобного подхода

—

его гибкость. Можно дополнять и изменять

продолжающую работать систему.

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

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

не книги, равно применимы и к системам согласования, хотя кэширование и ре-

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

того,

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

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

Вопросы и задания

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

ний, описанные в главе 2?

Отсутствие ссылочной связности в TIB/Rendezvous компенсируется адреса-

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

связности в этой системе?

Опишите реализацию системы публикации/подписки на основе системы оче-

редей сообщений, такой как MQSeries компании IBM.

Во что на самом деле разрешается имя темы в TIB/Rendezvous и как протека-

ет это разрешение?

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

ний в системе TIB/Rendezvous.

6. Когда в ходе транзакции TIB/Rendezvous сообщение доставляется процес-

су Р, процесс подтверждает доставку. Можно ли на уровне транзакций сде-

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

чески?

Предположим, что процесс в системе TIB/Rendezvous реплицируется. Приве-

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

реплицированными процессами более одного раза.

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

ликации процессов в системе TIB/Rendezvous?

9. Опишите простую схему для PGM, которая позволяла бы получателям обна-

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

следовательности.

10.

Могут ли журналы регистрации в TIB/Rendezvous, реализованные в виде

файлов, гарантировать, что сообщение, даже при наличии отказавших про-

цессов, не будет потеряно?

И. Как следовало бы реализовать в TIB/Rendezvous модель согласования на ос-

нове генеративной связи?

12.

Не считая отсутствия временной связности в Jini, в чем, по вашему мнению,

состоит наиболее существенная разница между Jini и TIB/Rendezvous с точки

зрения моделей согласования?

13.

Срок аренды

Jini всегда определяется его продолжительностью и никогда

—

в виде абсолютного значения времени истечения аренды. Почему?

14.

В чем состоят наиболее серьезные проблемы масштабирования в Jini?

12.5.

Итоги 789

15.

Пусть в распределенной реализации JavaSpace кортежи реплицируются на

нескольких машинах. Приведите протокол удаления кортежа, в котором при

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

гонок.

16.

Представьте себе, что транзакция Г в Jini требует блокировки объекта, кото-

рый уже заблокирован другой транзакцией Т'. Опишите, что произойдет.

17.

Представьте себе, что клиент Jini кэширует полученный из JavaSpace кортеж,

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

JavaSpace.

Имеет

ли такое кэширование смысл?

18.

Ответьте на предыдущий вопрос для случая, когда клиент кэширует резуль-

таты, полученные службой поиска.

19.

Опишите простую реализацию отказоустойчивого пространства JavaSpace.

Глава 13

Библиография

13.1.

Литература для дополнительного чтения

13.2.

Список литературы

В предыдущих главах мы изучили самые разные темы. Эта глава призвана по-

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

ти распределенных систем и желающим расширить свои знания. Раздел 13.1

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

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

которые есть ссылки в предыдущих главах.

13.1.

Литература для дополнительного

чтения

13.1.1.

Введение и общие вопросы

Coulouris et

а1.,

Distributed Systems

—

Concepts and Design

Хорошая книга по распределенным системам. Темы, которые в ней освещаются,

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

организован совершенно иначе. В ней значительно больше сведений по распреде-

ленным транзакциям и меньше

—

по именованию и защите. В число учебных

примеров входят CORBA и распределенная операционная система Mach.

Chow and Johnson, Distributed Operating Systems

and Algorithms

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

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

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