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

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

11.2.

Lotus Notes 741

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

после но-

мера

/Ь,

то эти два документа можно без опаски объединить в один, как показано

на рис.

11.21.

Такую возможность мы получаем из-за отсутствия конфликтую-

щих модификаций. Другими словами, изменения, сделанные в Л, не конфликту-

ют с изменениями, сделанными в В.

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

чае Notes выбирает один из документов «победителем», делая другой «проиграв-

шим». Победителем объявляется копия с большим последовательным номером

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

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

тификаторе инициатора самую позднюю отметку времени).

Репликация в кластере

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

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

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

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

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

Для этой цели каждый сервер поддерживает очередь событий модификации,

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

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

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

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

события удаляются из очереди.

11.2.7.

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

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

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

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

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

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

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

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

11.2.8.

Защита

Основу механизмов защиты в любой системе Notes составляет аутентификация

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

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

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

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

доступом в Notes.

742 Глава

11.

Распределенные системы документов

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

Для аутентификации пользователей и серверов Notes использует криптографию

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

тов,

содержащих открытый ключ. Основой этой схемы является доверие к серти-

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

открыты!! ключ, который

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

тифицируемому отправителю. В Notes уделяется особое внимание подтвержде-

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

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

С точки зрения за!циты Notes различает три типа сугцностей: пользователи,

серверы и сертифицирующие ор1^анизации. Каждая из этих сущностей известна

системе по ее

удостоверению

(identity), которое реализовано в виде файла, содер-

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

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

{открытый

ключ,

закры-

тый ключ). Одна пара, 512-битные ключи RSA, используется для шифрования

данных за пределами Соединенных Штатов; другая пара, 630-битные ключи, соз-

дается для шифрования данных в Соединенных Штатах, а также для аутентифи-

кации и подписания сообщен!4Й. Кроме того, создается сертификат, который

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

к которой подключается пользователь. Понятно, что использовать эту подпись

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

Вся эта информация хранится в файле удостоверения пользователя системы

Notes.

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

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

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

внутри системы. Файлы удостоверений сертифицирующих организаций обычно

хранятся в физически защищенном месте.

Notes поддерживает иерархию сертификатов. Другими словами, при добавле-

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

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

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

подтверждения правильности сертификата системного администратора можно ис-

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

Предположим теперь, что Алиса хочет аутентифицировать себя для Боба.

Давайте сначала рассмотрим вариант, когда Алиса и Боб работают в одной орга-

низации, скажем, в университете Franeker (FU), но Алиса

—

на факультете вы-

числительной техники (Department of Computer Science, CS), a Боб

—

на элек-

тротехническом факультете (Department of Electrical Engineering, ЕЕ). Алиса

и Боб имеют в своих файлах удостоверений открытый ключ университета

Franeker.

Алиса посылает свои сертификаты Бобу, а Боб проверяет открытые ключи,

содержащиеся в этих сертификатах, придерживаясь следующих правил:

-¥ все открытые ключи, хранящиеся в файле удостоверения Боба, являются

доверенными для Боба;

11.2.

Lotus Notes 743

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

низацией, открытый ключ которой Боб хранит в своем файле удостовере-

ния;

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

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

Алиса может передать Бобу два сертификата: сертификат

[А,

К\]ЕЕ,

содержа-

щий ее открытый ключ и подписанный

ЕЕ,

и сертификат

[ЕЕ,

K^^E]FUy

содержа-

щий открыты!! ключ ЕЕ, но подписанный

FU,

как показано на рис. 11.22. Боб

будет доверять

К^^ЕУ

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

щего сертификата, используя открытый ключ

FU,

который хранится в его файле

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

Боба. Применение второго правила позволяет Бобу поверить в правильность

К'^-Е-

Kpu хранится в файле

удостоверения Боба

го

[EE.K^EEKFUJ

[А,К;]ЕЕ

Боб

доверяет Kpu

принимает К^^

^FU

ьоо

доверяет гч^^

принимает К;^

Рис.

11.22.

Подтверждение правильности открытых ключей в Notes

Теперь Боб может проверить правильность сертификата \А, iC^]££. На основа-

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

дал Алисе открытый ключ К\, и по этой причине он верит, что открытый ключ,

присланный Алисой, действительно принадлежит ей.

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

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

ганизации, открытый ключ которой Алиса и Боб хранят в своих файлах удосто-

верений. В нашем примере это открытый ключ университета Franeker. Однако

если Алиса и Боб работают в разных университетах, проверка сертификатов Али-

сы будет невозможна.

Решение проблемы состоит в использовании перекрестных сертификатов

(cross

ceitificates), которые явно описывают обоюдное доверие. Так, например,

если Алиса работает в техническом университете Lommel (Technical University

of Lommel, TUL), то чтобы заставить Боба поверить ее собственному открытому

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

подписанный FU.

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

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

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

прос отправителю так, как мы описывали в главе 8. Дополнительные подробно-

сти по вопросу аутентифр1кации в Notes можно найти в

[317].

744 Глава 11. Распределенные системы документов

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

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

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

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

11.8.

Для

серверов списки контроля доступа {Access

Control

Lists,

ACL) явно определяют,

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

просы на сервер и на какой конкретно порт этого сервера. Списки контроля дос-

тупа

—

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

Таблица 11.8. Субъекты контроля доступа в Notes

Субъект Описание

Серверы Списки ACL определяют права доступа к серверам и портам

Рабочие станции Списки ECL определяют права на выполнение сценариев

и другого исполняемого кода

Базы данных Списки ACL определяют права различных типов пользователей

Файлы Списки ACL используются для контроля доступа через

web-клиентов

Заметки конструкции Списки ACL управляют представлением документов

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

Для рабочих станций Notes поддерживает списки контроля исполнения (Exe-

cution

Control

Lists,

ECL), явно описывающие ограничения, налагаемые на испол-

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

заметок. Так, например, исполняемому коду ECL может ограничить доступ к ло-

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

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

расширение модели сита, описанной в главе 8, с предоставлением конкретному

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

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

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

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

щиты не обеспечивается.

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

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

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

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

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

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

тах. Контроль доступа к базе данных подразумевает также разнообразные допол-

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

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

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

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

го,

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

11.3.

Сравнение WWW и Lotus Notes 745

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

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

мер,

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

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

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

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

пользователям права на исполнение этой роли.

И, наконец, каждый документ также имеет соответствующий ему список ACL.

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

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

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

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

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

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

[272].

11.3.

Сравнение WWW и Lotus Notes

World Wide Web и Lotus Notes ~ две наиболее распространенные распределен-

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

Философия

Обе системы, Web и Lotus Notes, используют простую модель клиент-сервер,

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

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

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

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

Среда Web недалеко ушла от традиционной модели, в которой документ пред-

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

ды разметки на языке HTML или одном из новых языков (например, XML). Од-

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

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

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

такие как сценарии и апплеты.

По мере того как Web продолжает развиваться, HTML как язык разметки по-

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

документа. Кроме того, XML отделяет структуру документа от его представле-

ния, в то время как в HTML они смешаны «в кучу».

Модель, лежащая в основе Lotus Notes, значительно отличается от модели,

принятой в Web. Основным элементом данных в Notes является список элемен-

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

воположность Web заметка

—

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

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

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

746 Глава

11.

Распределенные системы документов

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

конструкции.

Другое отличие между Web и Lotus Notes состоит в том, что в Notes делается

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

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

и т. п. В Web для этой цели используются выделенные механизмы.

Связь

Взаимодействие в Web происходит по специальному протоколу HTTP, который

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

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

Взаимодействие в Lotus Notes поддерживается при помощи традицрюнной под-

системы RPC. Кроме того, в Notes делается упор на механизмы связи верхнего

уровня, в основном электронную почту, для чего в этой срютеме предусмотрены

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

Следует отметить, что взаимодействие между процессами на одной машине

таклсе осуществляется по-разному. В Web поведение клиентов и серверов в этом

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

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

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

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

Такой подход улучшает переносимость многих приложений Notes.

Процессы

Сравнивая Web и Lotus Notes с ТОЧКР! зрения процессов, мы можем обнаружить,

что многие задачи решаются в них сходным образом. Наиболее важными кли-

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

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

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

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

щи встраиваемых модулей расширения.

В Lotus Notes клиенту также предоставляется графический интерфейс для

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

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

помощи форм, представлений и т. п. Поскольку клиент Notes предназначен для

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

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

Организация серверов этих двух систем также имеет сходные черты за ис-

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

работы с файловой системой. В противоположность ему сервер Notes Domino

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

Гибкость серверной части Web реализуется при помощи программ CGL Эти

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

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

ются к возможностям сервера Domino. Кроме того, web-серверы могут поддер-

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

11.3.

Сравнение WWW

Lotus Notes

747

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

как

автономный процесс. Параллельно главной программе может выполняться мно-

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

виде заданий сервера. Зада-

ния сервера можно сравнить

программами

CGI в

Web.

И Web,

Notes могут работать

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

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

единую структуру.

Ос-

новная разница между двумя системами состоит

степени прозрачности такого

объединения.

На

практике web-клиенты могут оставаться

полном неведении

о том,

что они

направляют запросы

кластеру серверов.

противоположность

им клиенты Notes должны составить список входящих

кластер серверов

и при

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

Именование

Разница

системах именования между Web

Notes напрямую связана

файло-

вой организацией

Web и

использованием баз данных

Notes.

Web документы

именуются

при

помощи

URN или URL.

Указатели

URL,

используемые

в Web

в настоящее время, обычно содержат

имя,

соответствующее локальному имени

файла документа, сохраненного

на

сервере.

противоположность

URL

имена

URN предназначены

для

Р1Спользования

качестве идентификаторов, никак

не

связанных

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

URN

может служить

но-

мер ISBN,

при

помощи которого идентифицируют книги.

В Notes документы

(и

другие типы заметок) имеют связанный

ними уни-

версальный идентификатор (UNID), являющийся правильным идентификатором.

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

для

именования заметки

досту-

па

ней.

Для

поиска записок

базе данных

нет

нужды

осмысленном

(с

точки

зрения человека) идентификаторе

из

строки символов. Однако Notes имеет так-

же интерфейс именования для Web. Он построен

на

базе указателя URL

вклю-

чает

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

также имена сервера

и ба-

зы данных,

которых хранится указанная заметка.

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

Что касается синхронизации,

то ее

поддержка

и в

Web,

и в

Notes минимальна.

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

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

ных серверах, отсутствует. Лишь

последнее время появились предложения

для

Web

по

поддержке коллективного редактирования

блокировкой совместно

ис-

пользуемых документов.

Кэширование

репликация

Если сравнивать средства кэширования и репликации, то между Web и Notes обна-

ружатся серьезные различия. Кэширование всегда играло

в Web

особую роль

—

оно повышало масштабируемость всей системы.

настоящее время традицион-

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

которых кэширование произ-

водится

как на

уровне пользователей,

так и на

уровне организаций, регионов

и стран. Кэширование эффективно потому,

что

большинство документов

в Web

748 Глава

11.

Распределенные системы документов

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

вание, особенно иерархическое кэширование, все менее эффективным.

Для Web были предложены и реализованы различные протоколы поддержа-

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

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

пор,

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

кэшированные копии не получат никакой информации об этом событии.

Мы не можем ничего сказать о роли кэширования на клиенте в Notes, по-

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

зуются совместно и при этом часто изменяются. По этой причине кэширование

в Notes должно быть менее эффективно, нежели в Web.

Репликация в Web традиционно поддерживается в форме создания зеркал

для сайта целиком. Однако этот механизм слишком негибок. С появлением

сетей доставки содержимого (CDN) стала расти популярность динамршеской ре-

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

верах, расположенных близко к пользователю. Непротиворечивость реплик обес-

печивается технологиями CDN.

В противоположность кэшированию репликация играет в Notes важную роль.

Она осуществляется при помощи эпидемических алгоритмов со слабой формой

распространения изменений. Такой подход приводит к конфликтам двойной

записи, которые требуется разрешать вручную. Хотя Notes старается разрешать

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

ными ситуациями. Если для однозначного разрешения конфликта требуется

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

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

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

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

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

Для обеспечения отказоустойчивости Web и Notes используют сход1П:»1е методики.

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

TCP.

Весьма интересен тот факт, что различного рода кластеры web-серверов

повышают доступность и увеличивает производительность каждого входящего

в кластер web-сервера. Были предложены и реализованы несколько подобных ре-

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

ра внешнего интерфейса, передающего запросы на один из серверов кластера.

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

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

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

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

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

менений.

Механизмы восстановления обеих систем, если они вообще существуют, огра-

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

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

11.3.

Сравнение WWW и Lotus Notes 749

Защита

Защита играет особую роль как в Web, так и в Notes. В Web защита обычно реа-

лизуется средствами защиты транспортного уровня (TLS), который позволяет

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

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

сервером.

В Notes используются сертификаты аутентификации. При этом особое вни-

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

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

поддерживается специфическая модель доверия. Обычно доверие устанавлива-

ется в соответствие с иерархической схемой именования, которая частично кон-

фигурируется при настройке сервера. С помощью перекрестных сертификатов

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

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

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

содерлсащих списки ACL. Таким образом можно определить самые разные права

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

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

Результаты сравнения систем Web и Notes представлены в табл. 11.9.

Таблица 11.9. Сравнение Web и Lotus Notes

Аспект WWW Notes

Базовая модель

Расширения

Модель хранения

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

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

процессами

Клиентский процесс

Клиентские расширения

Серверный процесс

Серверные расширения

Кластеры серверов

Именование

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

Кэширование

Репликация

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

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

Гипертекст

Мультимедиа, сценарии

На основе файлов

HTTP

Определяется операционной

системой

Браузер, редактор

Модули расширения

Напоминает файловый сервер

Сервлеты,

программы CGI

Прозрачные

URN.URL

В основном локальная

Расширенное

Создание зеркал, CDN

Надежная связь и кластеры

Явная поддержка отсутствует

Список текстовых элементов

(заметок)

Мультимедиа, сценарии

На основе базы данных

RPC,

электронная почта

Службы NOS

Браузер, редактор

конструкции

Предоставляются

операционной системой

клиента

Напоминает сервер

баз данных

Задания сервера

Непрозрачные

URL,

идентификаторы

В основном локальная

Не документировано

Слабая

Кластеры

Одиночного сервера

продолжение^

750 Глава 11. Распределенные системы документов

Таблица 11.9 {продолжение)

Аспект

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

Контроль доступа

WWW

в основном TLS

В зависимости от сервера

Notes

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

сертификатов

Расширенный, списки ACL

11.4. Итоги

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

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

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

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

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

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

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

торых

—

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

торую поддерживают как Web, так и Lotus Notes, существенно способствовала

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

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

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

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

доступ к этим документами. Если ссылки на документы могут пересекать границы

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

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

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

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

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

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

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

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

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

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

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

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

то,

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

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

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

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

щенного канала и последующем контроле доступа.

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

До какой степени электронная почта соответствует модели документов Web?

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

Что можно сказать о таком подходе применительно к файлам мультимедиа?